Opened 10 years ago

Closed 10 years ago

Last modified 10 years ago

#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)

resolving_bases.txt (2.3 KB ) - added by Iacopo Spalletti 10 years ago.
Traceback of resolving bases error
model_load.txt (3.2 KB ) - added by Iacopo Spalletti 10 years ago.
Traceback of model loading error

Download all attachments as: .zip

Change History (10)

comment:1 by Iacopo Spalletti, 10 years ago

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.

by Iacopo Spalletti, 10 years ago

Attachment: resolving_bases.txt added

Traceback of resolving bases error

by Iacopo Spalletti, 10 years ago

Attachment: model_load.txt added

Traceback of model loading error

comment:2 by Iacopo Spalletti, 10 years ago

I added the two tracebacks that occurs in the demo project:

  • resolving_bases.txt happens if the first migrated model in app_main.migrations.0001_initial is different from app_main.ClassPl thus resulting in error when app_sec.ClassB is scanned for bases
  • model_load.txt occurs when app_main.ClassPl is the first model declaration in app_main.migrations.0001_initial

comment:3 by David S, 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 anonymous, 10 years ago

Type: UncategorizedBug

comment:5 by Baptiste Mispelon, 10 years ago

Severity: NormalRelease blocker
Triage Stage: UnreviewedAccepted

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 Andrew Godwin <andrew@…>, 10 years ago

Resolution: fixed
Status: newclosed

In 24afb1d7a746da131212d050404bbe8837cf6f1d:

Fixed #22660: Doc'd you can't have unmigrated apps depend on migrated

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

In a067c61b94926f408e151ff5b4e0ce0d3b775183:

[1.7.x] Fixed #22660: Doc'd you can't have unmigrated apps depend on migrated

comment:8 by Andrew Godwin, 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.

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