#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):
Hi Luke,
I agree that having to remove the squashed migrations before you can
migrate (assuming the field is gone) isn't optimal. I also agree that it's
common to skip versions when updating third-party apps, and so it's best
if they don't have to rush the removal of outdated migrations.
I still think you're overstating the seriousness of this issue, for
several reasons:
1. It's a very rare occurrence. I looked back through the deprecation
timeline, and I can find exactly two model fields that Django has ever
deprecated (since 1.0, anyway), IPAddressField and XMLField. That's two
field removals over the course of 9 releases and 7-8 years (by the time
Django 1.9 is released). And the population of people affected by any
particular field removal will always be much smaller than the overall user
population, since unpopular fields are much more likely candidates for
removal. The acceptability of an inconvenient process has to be taken in
context of the frequency with which it is needed (and weighed against the
costs of implementing a smoother process). Regarding third-party apps, I
also use many and maintain several, and in the seven years I've used
Django I can't remember a single model field ever removed from a third-
party app that I use or maintain. I'm sure that it's happened in some apps
somewhere, but I don't think it happens all that often. Maybe you happen
to use/maintain apps that remove fields more frequently?
2. The third-party app in question of course has another option available
to them, the same one we have in Django and are discussing here: keep a
deprecated field stub around a while longer. Even if they don't want to
keep it around forever, that at least can give them all the time they need
to take the squashed-migrations route at a very leisurely pace, which
mitigates the "requires upgrade to intermediate versions" problem.
3. Migrations run during testing, and for some time we've encouraged
running tests with -W to notice deprecation warnings. So it doesn't seem
all that optimistic to think that _some_ user or developer of most widely-
used third-party apps might notice the deprecation warnings in their
migrations sometime before the release that actually removes the field.
(In other words, noticing a deprecation that's still hanging around in an
old migration is no different from noticing any other kind of deprecation
-- it's not any more likely to go unnoticed until the actual removal.)
So all in all, while it's far from ideal, I don't think documenting the
current state of things is nearly as horrible for third-party apps as you
make it out to be. And I'm not sure we have any other feasible option:
fundamentally, keeping a living historical record of model changes that
can be rolled forward and back (that is, migrations) is only possible if
you can still access the components involved in those changes. So you have
to keep those components around as long as you keep around the migrations
that depend on them.
I gave some thought to how we might improve the situation. Squash-replaced
migrations are never used (unless you're still in the midst of the block
of replaced migrations), just imported long enough to figure out their
dependencies and determine that they've been replaced. It might be
possible to create some kind of lazy field wrapper that could be used in
migration files to delay the actual import and instantiation of field
classes until the moment when something actually needs to access their
operations. But this would be complex to implement correctly, and I don't
think it really helps: when you're confident your users no longer need the
squashed migrations to be functional, you can just remove them. If you
still have users in the midst of the squashed migrations, then it isn't
safe to remove the referenced field, even if it's lazy-loaded.
--
Ticket URL: <https://code.djangoproject.com/ticket/23861#comment:7>
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 [email protected].
To post to this group, send email to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-updates/069.c2f94f93a1b44d0dd15aafcc7debd21c%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.
