#20439 closed Cleanup/optimization (fixed)
Deprecate IPAddressField in favour of GenericIPAddressField
| Reported by: | Sasha Romijn | Owned by: | |
|---|---|---|---|
| Component: | Database layer (models, ORM) | Version: | dev |
| Severity: | Normal | Keywords: | dceu13 |
| Cc: | eromijn@…, mike@… | Triage Stage: | Ready for checkin |
| Has patch: | yes | Needs documentation: | no |
| Needs tests: | no | Patch needs improvement: | no |
| Easy pickings: | no | UI/UX: | no |
Description
Since Django 1.4, we've added GenericIPAddressField, next to IPAddressField. The new GenericIPAddressField supports IPv4 as well as IPv6 addresses, and does normalisation of IPv6 addresses. It can also be configured to only accept IPv4 or IPv6 addresses.
As far as I know, IPAddressField has no current features that are not also available in a GenericIPAddressField. Therefore, I suggest that we, some time from now, deprecate IPAddressField, in favour of GenericIPAddressField.
For users, it is database-dependent whether IPAddressFields can just be replaced with GenericIPAddressFields: on PostgreSQL and SQLite, no changes are needed; schema changes are needed on MySQL and Oracle. Examples are listed in the 1.6 release notes https://docs.djangoproject.com/en/dev/releases/1.6/#storage-of-ip-addresses-in-the-comments-app, as we just made the same change for comments.
Change History (12)
comment:1 by , 11 years ago
| Cc: | added |
|---|
comment:2 by , 11 years ago
comment:3 by , 11 years ago
| Triage Stage: | Unreviewed → Someday/Maybe |
|---|
I'm almost sure we'll do this at some point. The ticket can be moved to Accepted if the discussion concludes that we should do it now.
comment:4 by , 11 years ago
Hey all, would it be possible to simply keep the old IPAddressField around as a proxy to GenericIPAddressField? I know it adds a bit of redundancy to the code, but would be one fewer backward-incompatible change to manage during upgrades. Additionally, people could continue to use the more concisely named IPAddressField. Just my thoughts...
comment:5 by , 11 years ago
I don't think so - they use different database column types on MySQL and Oracle. Worse, taking an IPAddressField column and using it to store GenericIPAddressField data may result in silent truncation.
comment:6 by , 11 years ago
| Cc: | added |
|---|
comment:7 by , 11 years ago
| Component: | Forms → Database layer (models, ORM) |
|---|---|
| Triage Stage: | Someday/Maybe → Accepted |
The mailing list thread has several +1's and no objections from core devs.
comment:8 by , 11 years ago
| Owner: | changed from to |
|---|---|
| Status: | new → assigned |
comment:9 by , 11 years ago
| Has patch: | set |
|---|---|
| Owner: | removed |
| Status: | assigned → new |
PR: https://github.com/django/django/pull/1688
I have added the deprecation to the release notes, the documentation of both IPAddressFields, and in the deprecation timeline. Warnings have been silenced in all relevant tests.
comment:10 by , 11 years ago
| Triage Stage: | Accepted → Ready for checkin |
|---|
The PR looks good. I only have trivial comments. I'll merge it.
comment:11 by , 11 years ago
| Owner: | set to |
|---|---|
| Resolution: | → fixed |
| Status: | new → closed |
Discussion started on django-developers: https://groups.google.com/forum/#!topic/django-developers/Ji_j2RmJ17w