Opened 12 months ago

Closed 11 months ago

Last modified 11 months ago

#22660 closed Bug (fixed)

Dependencies between non-migrated and migrated apps break migration

Reported by: yakky 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 yakky 12 months ago.
Traceback of resolving bases error
model_load.txt (3.2 KB) - added by yakky 12 months ago.
Traceback of model loading error

Download all attachments as: .zip

Change History (10)

comment:1 Changed 12 months ago by yakky

  • Needs documentation unset
  • Needs tests unset
  • Patch needs improvement unset

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.

Changed 12 months ago by yakky

Traceback of resolving bases error

Changed 12 months ago by yakky

Traceback of model loading error

comment:2 Changed 12 months ago by yakky

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 Changed 12 months ago by davids

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 Changed 12 months ago by anonymous

  • Type changed from Uncategorized to Bug

comment:5 Changed 11 months ago by bmispelon

  • Severity changed from Normal to Release blocker
  • Triage Stage changed from Unreviewed to 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 Changed 11 months ago by Andrew Godwin <andrew@…>

  • Resolution set to fixed
  • Status changed from new to closed

In 24afb1d7a746da131212d050404bbe8837cf6f1d:

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

comment:7 Changed 11 months ago by Andrew Godwin <andrew@…>

In a067c61b94926f408e151ff5b4e0ce0d3b775183:

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

comment:8 Changed 11 months ago by andrewgodwin

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