[Django] #24086: No pre_migrate signal is emitted if rolling back the migration history
Django
---------------------------------+--------------------------------
Reporter: andrewhayes1979 | Owner: nobody
Type: Bug | Status: new
Component: Migrations | Version: 1.7
Severity: Normal | Keywords: pre_migrate signal
Triage Stage: Unreviewed | Has patch: 0
Easy pickings: 0 | UI/UX: 0
---------------------------------+--------------------------------
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?
--
Ticket URL: <https://code.djangoproject.com/ticket/24086>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
Django
Reporter: andrewhayes1979 | Owner: nobody
Type: Bug | Status: new
Component: Migrations | Version: 1.7
Keywords: pre_migrate signal | Triage Stage: Unreviewed
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Changes (by andrewhayes1979):
* needs_better_patch: => 0
* needs_tests: => 0
* needs_docs: => 0
Comment:
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...
--
Ticket URL: <https://code.djangoproject.com/ticket/24086#comment:1>
Django
Reporter: andrewhayes1979 | Owner: nobody
Type: Bug | Status: closed
Component: Migrations | Version: 1.7
Severity: Normal | Resolution: worksforme
Keywords: pre_migrate signal | Triage Stage: Unreviewed
Easy pickings: 0 | UI/UX: 0
Changes (by timgraham):
* status: new => closed
* resolution: => worksforme
Comment:
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.
--
Ticket URL: <https://code.djangoproject.com/ticket/24086#comment:2>