[Django] #31278: Schema Editor Action: Pull Field Up
Django
-------------------------------------+-------------------------------------
Reporter: awiebe | Owner: nobody
Type: Bug | Status: new
Component: | Version: 3.0
Migrations | Keywords: pullup schemaeditor
Severity: Normal | runpython refactor inheritance
Triage Stage: | Has patch: 0
Unreviewed |
Needs documentation: 0 | Needs tests: 0
Patch needs improvement: 0 | Easy pickings: 0
UI/UX: 0 |
-------------------------------------+-------------------------------------
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.
--
Ticket URL: <https://code.djangoproject.com/ticket/31278>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
Django
-------------------------------------+-------------------------------------
Reporter: awiebe | Owner: nobody
Component: Migrations | Version: 3.0
Severity: Normal | Resolution: wontfix
Keywords: pullup schemaeditor | Triage Stage:
runpython refactor inheritance | Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
* status: new => closed
* resolution: => wontfix
Comment:
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.
--
Ticket URL: <https://code.djangoproject.com/ticket/31278#comment:1>