Opened 10 years ago

Closed 10 years ago

Last modified 10 years ago

#23556 closed Cleanup/optimization (fixed)

Allow migrations to depend on a migration only part of a squashed migration

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 Carl Meyer)

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/", line 216, in inner
    return test_func(*args, **kwargs)
  File "/home/markus/Coding/django/tests/migrations/", line 263, in test_loading_squashed_complex2
  File "/home/markus/Coding/django/django/db/migrations/", line 233, in build_graph
    self.graph.add_dependency(migration, key, parent)
  File "/home/markus/Coding/django/django/db/migrations/", 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:

Change History (6)

comment:1 by Carl Meyer, 10 years ago

Description: modified (diff)
Triage Stage: UnreviewedAccepted
Type: UncategorizedBug

comment:2 by Carl Meyer, 10 years ago

Markus' idea in IRC was that the migration system ought to be able to detect that since 3_squashed_5 replaces 5_auto, and 5_auto is gone, anything depending on 5_auto should instead be automatically considered to depend on 3_squashed_5 instead.

comment:3 by Markus Holtermann, 10 years ago

Type: BugCleanup/optimization

I looked into the issue a bit deeper and found my tests to be faulty. I'm working on a patch to make the error message more useful, though.

comment:4 by Markus Holtermann, 10 years ago

I updated my tests and slightly changed the behavior of the migration loader to check for if a migration could have potentially be replaced by a squash migration, but which wasn't used due e.g. partially be applied. E.g. if 3, 4 and 5 are squashed into 3_5 and a database has 3 applied, but not 4 and 5, 3_5 cannot be used. In this case removing 3 or 4 from the file system is not possible until 5 is applied on every instance.

Pull request:

comment:5 by Markus Holtermann <info@…>, 10 years ago

Resolution: fixed
Status: newclosed

In 85086c815873c4cf0bc2f1f2809119088cbe55f1:

Fixed #23556 -- Raised a more meaningful error message when migrations refer to an unavailable node

comment:6 by Andrew Godwin <andrew@…>, 10 years ago

In aac594f65f613929f904f2ecb466edfb573e17b4:

Merge pull request #3280 from Markush2010/ticket23556

Fixed #23556 -- Raise a more meaningful error message when migrations refer to an unavailable node

Note: See TracTickets for help on using tickets.
Back to Top