Say A.0002 and B.0001 are different leaf nodes for A.0001, and both alter the same field. Now, on a clean database, the order is pretty stable. If that order is A.0001, A.0002, B.0001, you'll always end up with the field from B.0001. This is also what the autodetector sees.
If you first create and apply the migrations A.0001 and B.0001, and then an update to A adds the new migration A.0002, the database will end up with the field from A.0002. The autodetector will still see the field from B.0001, and won't create a new migration, so if the final model has the field from B.0001, you have a mismatching database table. I think the fact that the order depends on which migrations have been applied is enough to require a merge migration. Marten Op dinsdag 8 september 2015 21:33:10 UTC+2 schreef Andrew Godwin: > > I still feel like merge migrations are necessary, if not only because > they're a way of reducing the potential collision area of migration > ordering from different branches, but it might be that the solver is > predictable enough that it's not a problem. Two separate branches in > migrations still don't have an order relative to each other, so if we > change the code in Django that does order resolution even slightly it could > result in different operation orders or even different "final" rendered > models. > > Andrew > > On Mon, Sep 7, 2015 at 5:16 PM, Shai Berger <[email protected] > <javascript:>> wrote: > >> Ok, two things: >> >> 1) Markus' idea of having more than one folder for migration modules seems >> reasonable enough. I disagree with his comment about the placement of >> merge >> migrations -- >> >> > Django needs to know where to >> > place the merge-migration. I'd go with the first item in the list >> >> I'd require an explicit selection by the user; I'd still want to make >> sure the >> selected path is one of those specified for migration modules, so a >> dialog for >> selection may be more appropriate than a command-line parameter. >> >> BUT >> >> 2) Emma's experiment, essentially, proves that the migration system can >> live, >> migrate, and generate new migrations with two leaf-migrations present. >> Which >> begs the question -- are merge migrations really necessary at all? I know >> why >> they were necessary for South, where migrations in an app were ordered >> linearly, but we have grown past that. >> >> If, as I now suspect, we actually don't need them, then the whole idea >> sounds >> much more reasonable. I still feel funny about a migration which belongs >> to >> one app and works on the models of another, and would prefer some better- >> looking solution -- e.g. "project migrations" (there are other reasons to >> think of them, like, special migrations to change swappable models); but >> unless some such idea gets some backing, I'd be only -0 on this. >> >> Shai. >> > > -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/f621c8bd-9c87-4c79-a99c-caa13365368f%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
