Opened 2 years ago

Closed 2 years ago

Last modified 2 years 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 2 years ago.
Traceback of resolving bases error
model_load.txt (3.2 KB) - added by yakky 2 years ago.
Traceback of model loading error

Download all attachments as: .zip

Change History (10)

comment:1 Changed 2 years 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 2 years ago by yakky

Traceback of resolving bases error

Changed 2 years ago by yakky

Traceback of model loading error

comment:2 Changed 2 years 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 2 years 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 2 years ago by anonymous

  • Type changed from Uncategorized to Bug

comment:5 Changed 2 years 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 2 years 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 2 years 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 2 years 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