Django et migration sud avec conflits (0007_two… et 0007_one) comment résoudre?

Question

Je souhaite utiliser south dans mon projet django en tant qu'outil de migration, mais je rencontre un problème d'utilisation de south dans un scénario multi-utilisateur:

Deux développeurs travaillant simultanément sur des machines différentes créent deux migrations avec le même numéro

• sur le premier PC: 0007_extend_lizard.py

• sur le deuxième PC: 0007_swap_name_adopter.py

Dans ce cas, je peux exécuter ./ manage migrate --merge ou ./ manage migrer 0006 (annulation) et réexécuter . < code> ./ manage migrate . MAIS quand je veux ajouter un nouveau champ dans models.py et exécuter ./ manage startmigration southdemo --auto , alors south obtient models = {} méta-données de la dernière migration, et il manque des informations de la première migration. Le résultat est la création de la migration 0008 avec la création de nouvelles modifications (!!!) à partir du premier 0007.

Quel est le meilleur moyen de résoudre ce problème?

Je pense actuellement à deux options:

• Fusionnez manuellement la migration 0007 dans un fichier, puis effectuez la migration (mais vous devez exécuter une opération "rollback")

• Déplacez manuellement models = {} manquant dans la méta 0007, puis le prochain - auto dans 0008 fonctionnera parfaitement.

Quelle est la meilleure option? Ou y at-il autre chose qui me manque?

Answer 1

Après avoir effectué migrate --merge ou rollback-and-migrate, si vous savez que la migration la plus récente contient maintenant des modèles gelés inexacts, je créerais simplement une nouvelle migration non-op mise à jour des modèles gelés. Il suffit d’exécuter ./ manage.py startmigration myapp --empty freeze_noop . Désormais, vos modèles figés seront à jour pour la prochaine fois que vous souhaitez détecter automatiquement une véritable migration.

Peut-être qu'il semble un peu moche de créer une migration non-op, mais pour moi, cela semble plus clair que l'une des options d'édition manuelle de l'historique que vous avez suggérées. Vous pouvez considérer la migration no-op comme l’équivalent d’un "engagement de fusion". dans un DVCS.

Ce problème doit être mentionné dans la cette section de la documentation sud ; J'ai enregistré un problème . (Mise à jour: maintenant c'est le cas.)