Further, my reading of the source seems to indicate that the migrations are loaded all at once for all INSTALLED_APPS as part of the MigrationLoader init and the decision about whether or not to run them made at this time as well in the migration_plan which leads me to believe that the change in the django_migrations table I made earlier in the sequence of migrations won't affect the decision to run the <new name> migrations as that decision has already been made earlier in plan creation.
On Thursday, June 16, 2016 at 4:06:39 AM UTC-7, Doug Donaldson wrote: > > I have a website with a number of smaller internal apps. I want to break > some of them out into reusable apps and I'm starting with a simple one. It > has a single model and a single initial migration representing it. Very > simple, no foreign keys etc. > > I did this: http://stackoverflow.com/a/8408131 and, as part of that, > updated django_migrations table to change old app label to new app label. I > did all these steps in a single RunSQL data migration in my core app which > is listed first in my APPS settings list: > > operations = [ > migrations.RunSQL( > [("UPDATE django_content_type SET app_label=%s WHERE > app_label=%s", [NEW_APP, OLD_APP])], > [("UPDATE django_content_type SET app_label=%s WHERE > app_label=%s", [OLD_APP, NEW_APP])], > ), > migrations.RunSQL( > "ALTER TABLE " + OLD_APP + "_contact RENAME TO " + NEW_APP + > "_contact", > "ALTER TABLE " + NEW_APP + "_contact RENAME TO " + OLD_APP + > "_contact" > ), > migrations.RunSQL( > [("UPDATE django_migrations SET app=%s WHERE app=%s", > [NEW_APP, OLD_APP])], > [("UPDATE django_migrations SET app=%s WHERE app=%s", > [OLD_APP, NEW_APP])], > ) > ] > > The console output seems to suggest the core migration is indeed running > before the <new app label> migration tries. > > Even though the django_migrations table seems to be updating the app_label > properly (step 3) the 0001_initial migration in the newly renamed app still > tries to run. It fails since it's just a create and the table it wants to > create already exists since the earlier table rename (step 2) made it so. > > I guess my general question is on the isolation level of the RunSQL > migrations. Should I expect the migration for <new app> to see it doesn't > need to run because django_migrations was updated one step earlier which > should now say <new app label> has already run 0001_initial? > > Doug > -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. Visit this group at https://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/450007ee-7a98-4cfd-bb74-f57e54ddaed2%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
