Hello all, I had the same problem with Django 1.8 project with 76 applications and 229 migrations in total. Even when the project was fully migrated and you execute *manage.py migrate* it takes 90 seconds after the message "*No migrations to apply.*" to finish.
If I upgrade to Django 1.9 then the time is about 40 sec (reduced by half but still a lot). I looked at *migrate* command and put some prints to see from where comes the slowness. I saw that it is when Django check if there are changes in models which are not reflected in migrations (Django is doing this not only when you run *makemigrations* but even when you are running migrate). You can workaround this by running: *manage.py migrate --verbosity=0* But when I'm developing I want some verbosity and I started investigation. I patched *django.db.migrations.graph.MigrationGraph.make_state* to print the time needed for every migration to make the state. Then I saw that the first 53 migrations took under 1ms but all next needed more than 100ms per migration (some even more than 3sec). The time for individual migration in Django 1.9 was about twice as fast compared to Django 1.8. But still the problem started from the same migration. Then I deleted all migrations for the problematic app and created new initial migration. Now when I see the timing for making the state from migrations I saw that now 122 migrations took under 1ms (even migrations that before took more than 1 sec). Then I repeated the procedure of "squashing" migrations (actually deleting and recreating initial migration) for slow apps (4 out of 76 apps in total) and now the state from all my 209 migrations is ready for about 1 ms (even on Django 1.8). In the problematic migrations I sow in operations *migrations.RenameModel*. Probably some in rename procedure or I don't know is preventing next migrations to create state faster. I still have data migrations (*migrations.RunPython*) and they do not slow down making the state from migrations. The project is too big and depends on many 3th party apps and is not easy task to migrate it to Django 1.10 or even 1.11 to test if it will be fast without modifying the migrations and I don't have enough spare time to do it. I hope that this information can help for further investigation of the slowness of making the model state from migrations. Regards, Venelin Stoykov неделя, 10 януари 2016 г., 22:07:45 UTC+2, Shai Berger написа: > > On Sunday 10 January 2016 08:09:33 Carl Meyer wrote: > > On 01/09/2016 09:29 AM, Shai Berger wrote: > > > There are two kinds of data migrations, generally speaking. > > > > > > [...] > > > > > > The other is migrations which *create* data -- fill in tables for > > > database- implemented-enums, for example. If you remove these, you are > > > going to break your tests (if you do this and haven't broken your > tests, > > > your tests are missing -- I'd go as far as calling them broken). > > > > I consider this second kind of data migration to be marginally smelly, > > and avoid it whenever possible. > > It should be noted that this kind of migration is what we recommend > officially > as a substitute for initial_data fixtures: > > > https://docs.djangoproject.com/en/1.8/howto/initial-data/#automatically-loading-initial-data-fixtures > > > 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 django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at https://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/d42211a5-9711-49b9-95e5-fa459e61daa0%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
