Opened 10 years ago

Closed 10 years ago

Last modified 10 years ago

#23818 closed Bug (duplicate)

Migration operations can't really conceptually deal with a model re-parenting.

Reported by: ris Owned by: nobody
Component: Migrations Version: 1.7
Severity: Normal Keywords: MTH inheritance migrations
Cc: info+coding@… Triage Stage: Unreviewed
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no


I think I explained it best in IRC:

<ris> from what i can see, it is impossible to use migration operations to change the "bases=" of an already existing model
<ris> makemigrations will change the xxx_ptr_id fields, but the internal model representation will always think it's a child of/not a child of what it was originally created as
<ris> which makes shit hit the fan further down the line
<ris> basically, am i right in thinking this?
<FunkyBob> ris: doesn't quite sound right...
<ris> FunkyBob: reading the only place bases= is mentioned is in CreateModel
<ris> and when you do migrations (using makemigrations) where a model gets re-parented (multi table inheritance) it never issues any operations regarding the actual parentage of the model
<ris> just does the mechanics of moving the xxx_ptr_id around
<ris> so the in-memory representation of the model structure never realizes it's been reparented
<FunkyBob> I see
<FunkyBob> it does seem like an unusual thing to want to do...
<ris> mmmmmnot really
<ris> reorganize your model structure
<ris> that's what migrations are for
<FunkyBob> as much as I like using django-polymorphic, MTI is not something I often find a need for
<ris> FunkyBob: perhaps the immediate solution would be to squash my migrations up to the point just after the re-parentage
<ris> FunkyBob: allowing the squashed migration to contain a CreateModel with the new bases=
<ris> FunkyBob: although looking more closely it does issue an AlterField setting parent_link=True on the OneToOneField
<ris> but i don't know if that's enough

Essentially, the in-memory representation built up from a series of migration operations doing a re-parenting won't acknowledge that the bases have changed, meaning they won't quite behave right in RunPython operations etc.

The workaround seems to be building a squashed representation that will then exhibit the correct properties once you've progressed beyond this point.

Change History (2)

comment:1 by Markus Holtermann, 10 years ago

Cc: info+coding@… added
Resolution: duplicate
Status: newclosed

Looks to me like a duplicate of #23521. Can you reopen the ticket if it isn't, please.

comment:2 by ris, 10 years ago

It's highly interrelated. I'll post my input in that bug.

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