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

[Markus Holtermann]

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

[Carl Meyer]

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.

[Markus Holtermann]

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.

[Markus Holtermann]

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: ​https://github.com/django/django/pull/3280

[Markus Holtermann <info@…>]

In 85086c815873c4cf0bc2f1f2809119088cbe55f1:

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

[Andrew Godwin <andrew@…>]

In aac594f65f613929f904f2ecb466edfb573e17b4:

Merge pull request #3280 from Markush2010/ticket23556

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