Comment by wiredfool
There are some subtle edge cases in the django migrations where doing all the migrations at once is not the same as doing migrations one by one. This has bitten me on multiple django projects.
There are some subtle edge cases in the django migrations where doing all the migrations at once is not the same as doing migrations one by one. This has bitten me on multiple django projects.
Ok, from memory --
There's a pre, do and post phase for the migrations. When you run a single migration, it's: pre, do, post. When you run 2 migrations, it's: pre [1,2], do: [1,2], post: [1,2].
So, if you have a migration that depends on a previous migration's post phase, then it will fail if it is run in a batch with the previous migration.
When I've run into this is with data migrations, or if you're adding/assigining permissions to groups.
Did you mean migration signals (pre_migrate and post_migrate)? They are only meant to run before and after the whole migration operation, regardless of how many steps are executed. They don't trigger for each individual migration operation.
The only catch is they will run multiple times, once for each app, but that can also be prevented by passing a sender (e.g. `pre_migrate.connect(pre_migrate_signal_handler, sender=self)` if you are registering them in your AppConfig.ready method).
Does that affect the autogenerated migrations at all? Teh only time I ran into that issue as if I generated a table, created a data migration and then it failed because the table was created same transaction. Never had a problem with autogenerated migrations.
What a crazy design, why don't they just do pre1 do1 post1 pre2 do2 post2?
There’s like an atomic flag you can pull it out of the transaction . Solves a lot of these issues.
Can you give an example how this would happen?