#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
-----------------------------+--------------------------------------
Changes (by spookylukey):
* component: Uncategorized => Migrations
Comment:
@carljm this solution doesn't work, unfortunately, at least not with the
current implementation. (I've tested this with an actual project).
If you squash the migrations, then you end up with a new migration that
doesn't access `models.IPAddressField`. But the old migrations still
access `models.IPAddressField`, and when you run `./manage.py migrate`
both the old and the new migrations are imported, so you still get an
`AttributeError` from the replaced migrations.
This could possibly be fixed by importing files that look like squashed
migrations first (which can be guessed from the file name), and importing
the ones they replace only once it has been established that this is
necessary. However, guessing squashed migrations from the file name is
fragile, and will break when you get to the stage of squashing migrations
another time (i.e. squashing migrations that were themselves squashed).
And we will get to the that stage, especially if squashing migrations is
the recommended way of dealing with the problem of removed fields.
A possible solution to these further problems is that if a migration is a
squashed migration (has the `replaces` attribute), we raise an error if it
'looks like' a squashed migration from its file name, and vice versa. We'd
need to change the docs, too, to say that when you transition a squashed
migration to a normal migration, you must remove the 'squashed' bit from
the file name: https://docs.djangoproject.com/en/dev/topics/migrations
/#squashing-migrations
In this way, we can know for sure that we can find the squashed migrations
first, and not import the ones they replace.
I'm still uncomfortable with forcing this on people. Migrations are hard
enough without forcing people to squash things simply to keep our code
base tidy. I actually prefer the 'crazy' idea of dynamically importing
compatibility shims when migrations are running. However, we also need a
solution for 3rd party libraries - i.e. 3rd parties who have model fields
that are referenced by other projects, which they then deprecate and
remove, causing the same breakage that removing `IPAddressField` will.
We need a documented solution that will allow us and other Django
libraries to do the right thing relatively easily, and know immediately if
they have done the wrong thing. Releasing broken migrations which then get
applied for some people is a really nasty situation to be in. The only
nice thing about the current situation is that if you remove a field, all
migrations will break straight away and you won't be able to run any of
them.
I'm guessing Andrew's input on this would help! I'm categorizing this as
'Migrations' for that reason.
A simpler solution might be something like:
* remove all the implementation of `IPAddressField` that is not needed for
migrations
* make it inherit from `RemovedField`, which has some magic behaviour:
when migrations are running, it works fine, but otherwise it throws an
exception to stop it being instantiated.
--
Ticket URL: <https://code.djangoproject.com/ticket/23861#comment:3>
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.1149babe3083e40d1435d4fd59cde153%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.
