Add proper support for pre/post migrate/sync signals.
Review Request #10582 — Created June 7, 2019 and submitted
We were trying to emit
apply_migrations(), which was always intended to be temporary. While
emitting them there sort of worked at one point (when there was only one
migration phase), it falls apart pretty hard with some apps with
multiple migration phases. The reason is that some apps will use the
post_migratesignal to inject some state into the database for the new
models, but this happens too soon when emitted during the initial
We also weren't emitting the
Django 1.6 and earlier (1.7 and 1.8 would emit them for
To solve all this, this change does four things:
It switches to emitting the
pre_migratesignal only once, before
any migrations are applied, and
post_migrateonly once, after all
migrations are applied.
It introduces a full migration plan that encompasses all phases of
the migrations, which allows us to provide some useful state in these
signals. This is important as some apps listen to
then modify the migration instances that are to be later applied.
It also splits
apply_migrations()into three functions:
finalize_migrations(). This allows repeated alterations of the same
migration state, and a single final model rendering phase, better
mirroring what's done directly in Django's
post_syncsignals on Django 1.6 and
Unit tests pass on all supported versions of Django.
Manually tested population of a new database and upgrades of an
existing one (utilizing both migrations and evolutions).
Updated to support
Revision 2 (+688 -124)
Checks run (2 succeeded)