#35463: Squash migrations inheriting dependencies from unsquashed migrations.
------------------------------------------+------------------------
Reporter: Gordon Wrigley | Owner: nobody
Type: Uncategorized | Status: new
Component: Migrations | Version: 4.2
Severity: Normal | Keywords: squash
Triage Stage: Unreviewed | Has patch: 0
Needs documentation: 0 | Needs tests: 0
Patch needs improvement: 0 | Easy pickings: 0
UI/UX: 0 |
------------------------------------------+------------------------
We have a large system with several apps and a lot of interdependent
migrations. Currently 17 apps and a total of 1,266 migrations.
Squashing this is very difficult. One of the things that makes it much
more difficult is the change associated with
https://code.djangoproject.com/ticket/25945 where by dependencies are
copied between squashed and unsquashed migrations.
This means that while the unsquashed migrations still exist in the
codebase the squash that replaces them is dependent on all of the things
the individual migrations are dependent on.
With large squashes on different apps that refer to each other this
frequently creates circular dependencies between squashes where they don't
actually exist.
The net effect of this is I have squashes where I know the squashes don't
depend on each other and the dependencies listed in the squashes are
chosen to not lead to them depending on each other, however they end up
depending on each other because they inherit the dependencies of the
migrations they replace.
We are addressing this by reverting part of that change so it no longer
copy dependencies onto the squash, trusting that the squash knows what
it's dependencies should be.
{{{#!python
def patch_squash_migration_dependencies():
from django.db.migrations.graph import MigrationGraph
patchy.patch(
MigrationGraph.remove_replaced_nodes,
r"""\
@@ -28,7 +28,3 @@
child.add_parent(replacement_node)
for parent in replaced_node.parents:
parent.children.remove(replaced_node)
- # Again, to avoid self-referencing.
- if parent.key not in replaced:
- replacement_node.add_parent(parent)
- parent.add_child(replacement_node)
""",
)
}}}
As an aside, generally cross app dependencies are from foreign keys. When
you add a foreign key to another app you need to depend on the migrations
in that app. Django depends on the most recent migration by default. But
AFAIK it only really needs to depend on the last migration where the PK of
the target table changed (usually when the table was added). It's probably
a lot of work but I suspect that having the migration system figure that
out would reduce a lot of circular dependency issues.
--
Ticket URL: <https://code.djangoproject.com/ticket/35463>
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 django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-updates/0107018f867f9adb-24ca5410-043f-4bd2-bc59-845a9f3c87fa-000000%40eu-central-1.amazonses.com.
