> > 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.
The order of migrations isn't something which is local to this feature, it is something which isn't fixed (probably by design, correct me if I'm wrong) and if it is not "the right way" to do it, maybe it should be part of another issue. Once again, correct me if I'm wrong but the only way to have different final rendered models would be the original third-party app defining/altering a field which has already been defined/altered by your app, resulting, in regards of the current proposal, in clashing fields. Creating a field which clashes with another app's field is something bad, there are nine chances out of ten that fixed migration order will not solve your overall problem: you created a field named the same as another field, except if you have a psychic connection with the original library's author you probably have a different usage for the field (however slight the difference may be) and, if you really need to upgrade that third party library, you have a whole other mess to fix than conflicting migrations so I am really wondering if this is worth the hassle. If you create two models with the same meta db_table, django doesn't come to your rescue and propose a solution, it is something you shouldn't have done and now you have to deal with it. I think this "edge case" is in the same area. 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. > A "project" is just a module, so if you create a "migrations" directory, add an __init__.py inside it and add it to your INSTALLED_APPS, you can start placing migrations inside it. That's actually where I put those "migrations for other apps" at the moment. And BTW, changing a swappable model is another "legitimate" example of a migration being created in a third party app (django.contrib.admin) while strictly using "recommended" features of Django. Cheers -- 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/fbea4a6f-e543-452e-8e38-fd1c41fdde86%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
