#22660 closed Bug (fixed)
Dependencies between non-migrated and migrated apps break migration
Reported by: | Iacopo Spalletti | Owned by: | nobody |
---|---|---|---|
Component: | Migrations | Version: | 1.7-beta-2 |
Severity: | Release blocker | Keywords: | migrations, dependencies |
Cc: | Triage Stage: | Accepted | |
Has patch: | no | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | no | UI/UX: | no |
Description
If models for app_sec
depends on models from app_main
(because of foreign keys or parentship) and models in app_main
have non trivial dependencies between them, migrate cannot resolve bases or cannot load models.
I've setup an example project https://github.com/yakky/migrations_poc to clarify class relationships.
Transform app_sec
in a migrated app or using run_before
attribute on app_main
migrations may not be a viable solution: app_sec
may not be under developer control or can be unknown at the time of creating migrations (e.g.: if app_main
is a general available application and app_sec
is a random application reusing models from app_main
).
Real world case here is django CMS
Attachments (2)
Change History (10)
comment:1 by , 10 years ago
comment:2 by , 10 years ago
I added the two tracebacks that occurs in the demo project:
resolving_bases.txt
happens if the first migrated model inapp_main.migrations.0001_initial
is different fromapp_main.ClassPl
thus resulting in error whenapp_sec.ClassB
is scanned for basesmodel_load.txt
occurs whenapp_main.ClassPl
is the first model declaration inapp_main.migrations.0001_initial
comment:3 by , 10 years ago
yes, seems reasonable that an app that doesn't use migrations can depend on the _final_ state of an app that does use migrations
could possibly get some mileage out of only attempting to render migration-less ("real") apps if anything depends on them
comment:4 by , 10 years ago
Type: | Uncategorized → Bug |
---|
comment:5 by , 10 years ago
Severity: | Normal → Release blocker |
---|---|
Triage Stage: | Unreviewed → Accepted |
This might be related to #22824 (the error is different but it happens in similar conditions).
Upgrading to release blocker, sadly.
Thanks.
comment:6 by , 10 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
comment:8 by , 10 years ago
This is unsolvable in any sensible timescale, so we're resolving this with a documentation fix saying unmigrated apps should not depend on migrated ones. Suggested solutions for dealing with third-party apps have been included.
This case is similar to #22568, but does not involve proxy models.
Also: squashing migrations or manually arranging classes in the migrations either solves the bases resolving issue or the model lookup one.