id	summary	reporter	owner	description	type	status	component	version	severity	resolution	keywords	cc	stage	has_patch	needs_docs	needs_tests	needs_better_patch	easy	ui_ux
23818	Migration operations can't really conceptually deal with a model re-parenting.	ris	nobody	"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."	Bug	closed	Migrations	1.7	Normal	duplicate	MTH inheritance migrations	info+coding@…	Unreviewed	0	0	0	0	0	0