#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 , 12 years ago
comment:2 by , 12 years ago
I added the two tracebacks that occurs in the demo project:
resolving_bases.txthappens if the first migrated model inapp_main.migrations.0001_initialis different fromapp_main.ClassPlthus resulting in error whenapp_sec.ClassBis scanned for basesmodel_load.txtoccurs whenapp_main.ClassPlis the first model declaration inapp_main.migrations.0001_initial
comment:3 by , 11 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 , 11 years ago
| Type: | Uncategorized → Bug |
|---|
comment:5 by , 11 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 , 11 years ago
| Resolution: | → fixed |
|---|---|
| Status: | new → closed |
comment:8 by , 11 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.