#36166: squashmigrations breaks backward migration detection
------------------------------------+--------------------------------------
Reporter: Klaas van Schelven | Type: Bug
Status: new | Component: Migrations
Version: 5.1 | Severity: Normal
Keywords: | Triage Stage: Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
------------------------------------+--------------------------------------
When squashing migrations, migrating back is broken when referencing a
now-replaced migration.
I have migrations as such:
* 0001_initial.py
* 0002_foomodel_bar.py
* 0001_squashed_0002_foomodel_bar.py squashing 0001 & 0002
* 0003_foomodel_after_squash.py depending on the squashed migration
(Django does this by default when making a new migration after squashing,
and it's the right thing)
However, after migrating fully, migrating back to the last replaced
migration does not actually undo 0003.
{{{
$ python manage.py migrate squashme
Operations to perform:
Apply all migrations: squashme
Running migrations:
Applying squashme.0001_squashed_0002_foomodel_bar... OK
Applying squashme.0003_foomodel_after_squash... OK
$ python manage.py migrate squashme 0002
Operations to perform:
Target specific migration: 0002_foomodel_bar, from squashme
Running migrations:
No migrations to apply.
(freshdjango) klaas@pop-os:~/dev/squashtest$ python manage.py migrate
squashme
Operations to perform:
Apply all migrations: squashme
Running migrations:
No migrations to apply.
}}}
Migrating even further back into that chain leads to inconsistent
migration history:
{{{
(freshdjango) python manage.py migrate squashme
Operations to perform:
Apply all migrations: squashme
Running migrations:
Applying squashme.0001_squashed_0002_foomodel_bar... OK
Applying squashme.0003_foomodel_after_squash... OK
(freshdjango) klaas@pop-os:~/dev/squashtest$ python manage.py migrate
squashme 0001_initial
Operations to perform:
Target specific migration: 0001_initial, from squashme
Running migrations:
Rendering model states... DONE
<=
shouldn't there be undoing of 0003?
Unapplying squashme.0002_foomodel_bar... OK
(freshdjango) klaas@pop-os:~/dev/squashtest$ python manage.py migrate
squashme
Traceback (most recent call last):
[..]
raise InconsistentMigrationHistory(
django.db.migrations.exceptions.InconsistentMigrationHistory: Migration
squashme.0003_foomodel_after_squash is applied before its dependency
squashme.0002_foomodel_bar on database 'default'.
}}}
Migrating back to the squashing migration instead (if you didn't do the
above) does what you'd expect:
{{{
(freshdjango) python manage.py migrate squashme
0001_squashed_0002_foomodel_bar
Operations to perform:
Target specific migration: 0001_squashed_0002_foomodel_bar, from
squashme
Running migrations:
Rendering model states... DONE
Unapplying squashme.0003_foomodel_after_squash... OK
}}}
[https://github.com/vanschelven/squashtest/tree/main/squashme/migrations
code sample here]
--
Ticket URL: <https://code.djangoproject.com/ticket/36166>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
--
You received this message because you are subscribed to the Google Groups
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion visit
https://groups.google.com/d/msgid/django-updates/01070194cda581dc-0b748c36-e0c1-49ee-aa94-fd4453de0985-000000%40eu-central-1.amazonses.com.
