Je rencontre le même problème. Une façon de contourner le problème est de laisser 'id' (auto-incrémenté) dans vos fixtures, et en supposant que vous avez effacé les données dans votre base de données, de lier les clés étrangères (dans vos fixtures) avec ce qu'elles devrait soit après l'auto-incrémentation.
En faisant ça, puisque vous avez quitté id
dans vos données de fixation, Postgres mettra à jour la séquence qu'il utilise pour attribuer des valeurs auto-incrémentées pour la table X (à partir de X_id_seq - vous pouvez psql ; \c ; \d (pour lister les dbs) ; select * from X_id_seq).
Une autre solution consiste à continuer à faire ce que vous (et moi) faisons, c'est-à-dire définir manuellement des identifiants qui s'incrémentent automatiquement, puis modifier d'une manière ou d'une autre la table de séquences X_id_seq pour définir sa dernière valeur à la valeur qu'elle devrait avoir.
Vous devrez probablement exécuter une requête sql manuelle via sequelize.
Une autre option encore consiste à réaliser vos propres montages via vos propres modèles. C'est ce que je faisais et que j'envisage sérieusement de faire à nouveau
Edit : aussi, si vous utilisez les sequelize-fixtures, vous pourriez vouloir jeter un coup d'oeil au dernier commentaire ici : https://github.com/domasx2/sequelize-fixtures/issues/43#issuecomment-147955330
Edit : problème ouvert : https://github.com/domasx2/sequelize-fixtures/issues/71
Edit : Comme solution temporaire avant de tout réécrire sans sequelize-fixtures, j'ai utilisé ce qui suit pour définir manuellement la séquence :
await db.sequelize.query(
`ALTER SEQUENCE "ItemInstances_id_seq" RESTART WITH ${itemInstances.length + 1};`
);
Je pense que le moment où vous le faites (avant / après le chargement des appareils) n'a pas d'importance puisque vous contournez la séquence de toute façon.