Opened 10 years ago
Last modified 10 years ago
#23556 closed Cleanup/optimization
Allow migrations to depend on a migration only part of a squashed migration — at Version 1
Reported by: | Markus Holtermann | Owned by: | Markus Holtermann |
---|---|---|---|
Component: | Migrations | Version: | dev |
Severity: | Normal | Keywords: | |
Cc: | Markus Holtermann | Triage Stage: | Accepted |
Has patch: | no | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | no | UI/UX: | no |
Description (last modified by )
If a migration depends on another migration that is part of a squashed migration (e.g. 6_auto
depends on 5_auto
which is part of 3_squashed_5
) removing the squashed migration (e.g. 5_auto
) leads to a KeyError
:
Traceback (most recent call last): File "/home/markus/Coding/django/django/test/utils.py", line 216, in inner return test_func(*args, **kwargs) File "/home/markus/Coding/django/tests/migrations/test_loader.py", line 263, in test_loading_squashed_complex2 loader.build_graph() File "/home/markus/Coding/django/django/db/migrations/loader.py", line 233, in build_graph self.graph.add_dependency(migration, key, parent) File "/home/markus/Coding/django/django/db/migrations/graph.py", line 42, in add_dependency raise KeyError("Migration %s dependencies reference nonexistent parent node %r" % (migration, parent)) KeyError: "Migration migrations.6_auto dependencies reference nonexistent parent node ('migrations', '5_auto')"
Thus the whole idea of squashmigrations
to be able to eventually remove old migrations is not really working out since a 3rd party app might depend on a specific migration.
I build a testcase: https://github.com/Markush2010/django/commit/9a983d4fe66c583858eb370497d0b66227690f79
Change History (1)
comment:1 by , 10 years ago
Description: | modified (diff) |
---|---|
Triage Stage: | Unreviewed → Accepted |
Type: | Uncategorized → Bug |