Schema Editor Action: Pull Field Up

[awiebe]

The schema editor is incapably of detecting when a field has been pulled-up into the parent class, and instead tries to delete a pulled-up field, and then add an equivalent field to the parent table, having deleted all of the data that was in the original column.

At the very least the schema editor should ask whether you intended to do a pull-up instead to prevent data loss. Below I will describe the procedure for performing a pull up in an automatic way. Even if not implemented as generated migrations, there should be an article on the procedure, in the same way there is for other quirky runpython use-cases.

Instead the schema editor should generate two migrations ( it can't do it atomically in one migration, or I couldn't figure out how to make that work when I write this kind of migration manually).

==Migration 1==
1.Add the pulled up field to the parent class, permit null, default null (so we don't have to set or consider any values)
2.RunPython Select all instances of derived objects using their default manager (emit warning if more than one, or just to say the default is used and edit the migration)
3.For each in (2) select, get the parent object through the _ptr field, and copy the old field value to the new field

NB if multiple fields try to add them upfront, and copy every value at once to prevent duplicate select queries.

==Migration 2==
Delete columns in child class, and proceed with any other schema changes that would normally be generated.

[Carlton Gibson]

I think this kind of composite operation is out-of-scope for the core framework.

What you describe sounds right: create the new field, do a data migration, delete the old field.
But I don't think we'd ship operations to do that for you.

I might say yes to a documentation example, but, beyond basics (and moving to a custom user model) I don't see that we catalogue various migration scenarios.
It would make a good blog topic I think.

Thanks.