#23861: IPAddressField removal will break migrations and test suites
-----------------------------+--------------------------------------
Reporter: spookylukey | Owner: nobody
Type: Bug | Status: new
Component: Migrations | Version: master
Severity: Normal | Resolution:
Keywords: | Triage Stage: Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-----------------------------+--------------------------------------
Comment (by carljm):
@spookylukey I'm aware that squashing alone doesn't fix it - that's why I
said "and later remove" in my comment. The intent with migration squashing
is that you can delete the squashed migrations once you are confident that
everyone who has started into the squashed set has migrated past it. For a
project's migrations this is pretty easy: once you deploy and migrate
once, you can remove the replaced migrations. For a third party project,
you'd do one release with a squashed migration, and then in the following
release you could remove the replaced migrations, and everything will work
fine as long as your users upgrade one release at a time and migrate at
each upgrade. (For future users who start in with the newest release,
there's no problem, it's as if the replaced migrations never existed at
all.)
The one potential problem with squashing is that a RunPython or RunSQL
operation in the squashed set can prevent the optimizer from optimizing
through -- for instance if you had an IPAddressField, then had a RunPython
or RunSQL operation, then later removed that field, the squashed migration
will still keep the field around in the early end of its operation list
because it has no idea what the RunPython/RunSQL might be doing, or
whether it might break without that field. So this case can require manual
modification of the squashed migration; in most cases that shouldn't be
too difficult, you just remove the field addition operation, modify
RunPython/RunSQL so it works without that field, and then remove the
field-removal operation afterwards. This can be documented.
There are certainly fiddly bits here, and I'm not necessarily opposed to
Django keeping field stubs around for longer than usual in some form to
reduce the impact of our own field removals. I just want it to be clear
that there is already a working solution to this problem that we can
document for third-party field removals, at least.
--
Ticket URL: <https://code.djangoproject.com/ticket/23861#comment:5>
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 django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-updates/069.393dc270c396e5d094790f78ba0c2f78%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.
