#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 |
Description
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.
Change History (2)
comment:1 by , 10 years ago
Cc: | added |
---|---|
Resolution: | → duplicate |
Status: | new → closed |
Note:
See TracTickets
for help on using tickets.
Looks to me like a duplicate of #23521. Can you reopen the ticket if it isn't, please.