No pre_migrate signal is emitted if rolling back the migration history

[andrewhayes1979]

Use case:

Suppose I have an app "myapp" with a model "MyModel", run makemigrations to generate 0001 and then migrate:

• I'll get both the pre_migrate and post_migrate signals fired when running the migration

If I then add a field to MyModel, run makemigrations to generate 0002 and then migrate:

• I'll also get both the pre_migrate and post_migrate signals fired.

(this was addressed in this ticket: https://code.djangoproject.com/ticket/23975)

If I now run "python manage.py migrate myapp 0001" to rollback the 0002 migration, I'll only get a post_migrate signal emitted, no pre_migrate.

The sync_apps() function that the pre_migrate signal emit code lives in is never called in this use case.

Desired behaviour:

• all calls to migrate should generate pre_migrate and post_migrate signals to bookend the start/end of database schema modifications

...the documentation for the pre_migrate signal currently states that it is fired only when installing an app, however the fix for https://code.djangoproject.com/ticket/23975 means this is no longer accurate.

...simply firing the 2 events anytime a database schema migration occurs (forwards or backwards) would be simpler and easier to understand, IMO

Also, as an aside, it would be nice if richer information were provided in the post_migrate signal in terms of a list of model-classes that were modified for e.g. I'm currently relying on database introspection in pre_migrate and post_migrate signal-handlers to watch for changes in model-schemas...since the migration-functionality knows what it has/hasn't run, it'd be nice if this information were shared out in the post_migrate signal perhaps?

[andrewhayes1979]

Addendum, the actual behaviour is slightly more confusing than first reported, try this:

myapp + MyModel, generate initial migration 0001, migrate:

• pre_migrate and post_migrate fired

add field to MyModel, makemigrations to generate 0002, migrate:

• pre_migrate and post_migrate fired

migrate back to 0001:

• only post_migrate fired (as reported above)

migrate forwards to 0002:

• only post_migrate fired (expected this to work the same as case #2, forwards migration from 0001 -> 0002)

add another field to MyModel, makemigrations to generate 003, migrate

• pre_migrate, post_migrate are fired (as expected)

...the current behaviour is slightly confusing...

[Tim Graham]

I couldn't reproduce the lack of the pre_migrate signal as you describe. Here's a test for Django's test suite that passes. I also tested manually by using the tutorial app and running python manage.py migrate polls 0001 after generating a second migration. I put a print statement in emit_pre_migrate_signal() and verified it was executed. Please reopen if I've missed something or if you can provide a failing test.

Regarding your aside (please create a separate ticket in the future), a similar feature request is tracked in #24100.