[Django] #23818: Migration operations can't really conceptually deal with a model re-parenting.
Django
parenting.
----------------------------+----------------------------------------
Reporter: ris | Owner: nobody
Type: Bug | Status: new
Component: Migrations | Version: 1.7
Severity: Normal | Keywords: MTH inheritance migrations
Triage Stage: Unreviewed | Has patch: 0
Easy pickings: 0 | UI/UX: 0
----------------------------+----------------------------------------
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 https://docs.djangoproject.com/en/1.7/ref
/migration-operations/ 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.
--
Ticket URL: <https://code.djangoproject.com/ticket/23818>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
Django
parenting.
Reporter: ris | Owner: nobody
Type: Bug | Status: closed
Component: Migrations | Version: 1.7
Severity: Normal | Resolution: duplicate
Keywords: MTH inheritance | Triage Stage:
migrations | Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Changes (by MarkusH):
* status: new => closed
* cc: info+coding@… (added)
* needs_better_patch: => 0
* needs_tests: => 0
* needs_docs: => 0
* resolution: => duplicate
Comment:
Looks to me like a duplicate of #23521. Can you reopen the ticket if it
isn't, please.
--
Ticket URL: <https://code.djangoproject.com/ticket/23818#comment:1>
Django
parenting.
Reporter: ris | Owner: nobody
Type: Bug | Status: closed
Component: Migrations | Version: 1.7
Severity: Normal | Resolution: duplicate
Keywords: MTH inheritance | Triage Stage:
migrations | Unreviewed
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Comment (by ris):
It's highly interrelated. I'll post my input in that bug.
--
Ticket URL: <https://code.djangoproject.com/ticket/23818#comment:2>