I’ve been thinking about the problem of large projects with many models and migrations, and circular cross-app dependencies. In such projects,
squashmigrations typically fails, and in many cases, one cannot even “declare migration bankruptcy” – the practice where you just delete all migrations from the code and the DB and start afresh: you can’t make the initial migration for app A because it depends on (i.e. has a model with an FK to a model in) app B, which depends on app C, which depends app A.
This is a different take on a problem which was tackled in 2 Ideas: New additions to makemigrations – the idea there was a somewhat dangerous operation to replace a whole set of migrations with new initial ones.
I’m suggesting that we add a
--no-deps flag to
makemigrations, this will create the models without the relationships; in
squashmigrations, I’m not entirely sure, but in general, try to get from the state before the first squashed migration to the state after the last squashed ones, again, without creating relationships and dependencies. The user will then be able to run
makemigrations for each (or all) of the apps, to create the relationships.
This will support the case not handled in the previous suggestion, where the FK dependencies are circular, preventing the creation of the new migrations.
squashmigrations can be more careful about the
RunPython (and other) operations.
This is just an initial thought; comments (including pointing out why I’m wrong and this can’t work or shouldn’t be supported) welcome.