#23818: Migration operations can't really conceptually deal with a model re-
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.
--
You received this message because you are subscribed to the Google Groups
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-updates/046.24629176a00a8c25fd2221c362c6b921%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.
