id	summary	reporter	owner	description	type	status	component	version	severity	resolution	keywords	cc	stage	has_patch	needs_docs	needs_tests	needs_better_patch	easy	ui_ux
24086	No pre_migrate signal is emitted if rolling back the migration history	andrewhayes1979	nobody	"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?
"	Bug	closed	Migrations	1.7	Normal	worksforme	pre_migrate signal		Unreviewed	0	0	0	0	0	0