--
You received this message because you are subscribed to the Google Groups "Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-develop...@googlegroups.com.
To post to this group, send email to django-d...@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
For more options, visit https://groups.google.com/groups/opt_out.
IPAddressField is meant for IPv4 addresses and GenericIPAddressField is for both IPv4 and IPv6. Most backends define different database data types for each of those fields. E.g. mysql is char(15) vs char(39). Forcing the larger data type on users doesn't make sense.
I understand your comparison, but the situation is a little different here. The integer fields you refer to actually have different storage size requirements in many database backends. But for GenericIPAddressField in PostgreSQL and SQLite, the column types are the same - INET and TEXT.
On MySQL, the type is not char(15) vs char(39), but varchar(15) vs varchar(39).
The storage size required for a varchar is the same for any length from 1 to 255: one byte to store the content length, and then the bytes of the content. So storage size or performance is not affected. On Oracle, it's VARCHAR2(15) vs VARCHAR2(39) - I assume they store it similar to MySQL.
In other words, if you replace an IPAddressField with a GenericIPAddressField and store the same data, storage size or database performance is not affected, even though the column type may need to be changed.
+1 to deprecating the old field. This caused me some confusion. Now migrations are in master, the upgrade path will be much simpler.
Is the legacy field releasable as a 3rd party package? It seems to be this would be difficult due to differing behaviour across DBs.
Marc