On Wednesday, 9 September 2015 12:29:59 UTC+2, Marten Kenbeek wrote: > > 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. > > > The order of migrations within a single app is fixed. That means the order > of the operations on a single model or table is also fixed. > This proposition introduces a variable order to migrations that alter the > same model, so yeah, this issue is local to this feature. >
I've had the case where migration order between apps was different between initialized and non-initialized database which crashed the migration process when running on a non-initialized database when using another "strongly advised against" behavior in a data migration (namely importing a model directly). So, since the only case where an fixed order between an "official" and a "non-official" leaf node is important is when using a a "strongly advised against" behavior, this is debatable. > 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. > > > Since we're talking about unsupported, undocumented ways to change models > anyway (like contribute_to_class), I think altering an existing > field is a very legitimate reason to create a new migration. For instance, > many people want to increase the length of the username field on the > default User model, and the upcoming 1.9 release will also alter the > username field again, resulting in the scenario I described above. So > unless > we explicitly warn against this in the documentation, we should find a > suitable solution for this. > Personnaly I've been talking about the case which, when running makemigrations, creates a migration in a third party app. There are several legitimate use-cases outside of contribute_to_class. Contribute_to_class is only one case and you have been warned against using it so a warning should be sufficient, shouldn't it? I would argue that if you need a longer username, you should use a custom user model extending AbstractUser (which would lead to one of the legitimate use-cases I just mentioned), which is the recommended way of doing it. To go further with your example, a fixed migration order will no solve your problem: to keep your existing data safe. If Django's default length for a username is still smaller than yours you won't be able to run the migration at all on an existing database (or it will truncate your existing usernames), so you'll have to manually fake run it on any production database. To have the field length set to your custom value with a fixed order, this would mean you have to run your migration after the new django.contrib.auth one, which is not possible since your migration has probably already run on the production database. (If your migration hasn't run yet on production database, simply delete it and re-run makmigrations, it will automatically depend on the latest migration for that app ;-) ) And if Django's default length for the username field is larger than your custom value, then your data will be safe unrelated to the order in which the migrations run. You may then either remove your change or re-create a new migration (which depends on the new django.contrib.auth migration) to reduce the length to whatever you want it to be if you feel it's necessary. So, yes, I still believe fixed migration doesn't bring much to this feature. Cheers, Emma -- 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/de3e7048-cd17-4bdd-b0b1-c8f7c3e5a1c8%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
