Very slow migrations with large numbers of tables

Using Django Using the ORM
8

I would eventually like to help solve this problem for Django, but I need to immerse myself in past efforts first. I will see about plugging in on one of the existing PRs, unless you think it would be better to start fresh, or if you would like me not to do any further work on this for now.

It’s worth giving the suite a run with your proposed changes. My first impression is that the reload_model changes will break any schema editor method that uses backward related cache to do things like rename objects or re-create foreign key constraints. For example, say that you have

  1. A series of migrations being applied where __fake__.Author and __fake__.Book are rendered. Both objects in memory have pointers to each other.
  2. Now you proceed with a migration that alters Author to Author' and result in calling reload_model for it. At this point Book still points at Author in memory and not Author' so if you have a follow up migration that introspect Book for reverse relationships it won’t point at Author' like it should.

The only really way to tell is to throw the test suite at it though which should be pretty straight forward. If the suite passes it’s a good sign for sure but we have been proven wrong plenty in the past and migration graph corruption bugs are very hard to diagnose as they basically require the reporters to provide us access to a subset of their project to reproduce.

I believe that it might be better to start fresh but given the efforts have pretty much stalled on this front and slow migrations remains a source of frustration for many Django users it’s definitely worth exploring alternative avenues.