Hi Michael, On Aug 25, 2013, at 12:07 AM, Michael Manfre <[email protected]> wrote:
> 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. > > IPAddressField and GenericIPAddressField are similar to the various integer > fields. When BigIntegerField was added to the core, IntegerField and > SmallIntegerField still had their purpose. 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. cheers, Erik -- 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 [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/django-developers. For more options, visit https://groups.google.com/groups/opt_out.
