#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):
Regarding IPAddressField, I've already said I don't have a problem with
keeping IPAddressField around (in some form) for longer than usual; I was
moving on to the question of whether we need to do something for the
general situation for third-party projects; frequency seems like a
relevant factor there.
You're right that deprecations raised by migrations are different in that
they are harder to get rid of - I was just pointing out that they aren't
any less likely to be noticed in the first place.
I looked back through the thread, and your proposal (at least the one I
found) is different from what I'd suggested. I don't think it's a good
idea to try to detect squash migrations by filename and load those first,
because that conflates the definition of a squash migration (one which
contains the 'replaces' key) with an incidental property (the default file
naming scheme used by the squashmigrations command). It's perfectly
legitimate to rename a squash migration file however you like, or even
write it yourself without using the squashmigrations command, so we
shouldn't push a solution that would break in those cases. That's why I
think we'd need to instead find a way to be able to import any migration
file without having to immediately import and instantiate all its
operations and their constituent fields.
I had suggested lazy wrappers for individual fields, but there may be an
even simpler approach possible, where the entire operations list is
wrapped in a function/method (and any imports of custom fields happen
within that function/method) rather than being a class attribute. There
may be problems I'm not thinking of, but I think that might not be very
hard.
I think your analysis of how that would actually simplify the upgrade path
is correct.
--
Ticket URL: <https://code.djangoproject.com/ticket/23861#comment:9>
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.b015b429d2abbc138c3caab33ea1728c%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.
