Hi Michael, On Aug 25, 2013, at 6:27 PM, Michael Manfre <mman...@gmail.com> wrote: > The code on master doesn't agree with your statement about mysql and sqlite. > sqlite - > https://github.com/django/django/blob/master/django/db/backends/sqlite3/creation.py#L26
SQLite doesn't actually have a CHAR type - it will consider both of these columns to be the TEXT type: http://www.sqlite.org/datatype3.html > mysql - > https://github.com/django/django/blob/master/django/db/backends/mysql/creation.py#L23 You are correct - I seem to have remembered incorrectly. >> 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. >> > I don't think that is true for all databases, nor should Django make that > type of assumption. Unless I've misunderstood how MSSQL works, which is > possible, it only adds a few bytes of overhead to the actual data. MSSQL is not a supported database in Django itself, so I have no idea, or control over, how the (Generic)IPAddressField types are stored in there. Let alone what the differences in storage size might be. >> 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. >> > This is probably true for some databases, but not guaranteed to be true for > all. With your correction on the MySQL datatypes, this is indeed not true for MySQL. It would introduce an overhead of 24 bytes. However, countering that are several good reasons to proceed with deprecation. IPAddressField has no model validation, which means that it will often allow storing IPv6 addresses. This may work, or may result in silent truncation or an error, depending on the database backend and it's settings. Should storing the IPv6 address work, then trying to edit that object through a ModelForm later, e.g. in the admin, will fail. These limitations are in no way obvious to any IPAddressField user. IPv6 addresses are not just encountered by users that consciously make a decision to support IPv6, and therefore would look deeper into support in fields. It is fairly common to see IPv6-mapped IPv4 addresses, like ::ffff::192.0.2.1, in REMOTE_ADDR. IPAddressField may truncate these silently or fail the query. As Aymeric points out, it is just confusing to our users. IPAddressField also has some issues regarding the handling of blank strings vs None. This may result in unexpected behaviour or failures on some databases, but can't be fixed as it would break backwards compatibility. These are fixed in GenericIPAddressField. To sum it up, the overhead may be an issue for users for which storage is very critical, and who will only need to store IPv4 addresses. Particularly the latter situation seems doubtful to me, as IPv6 adoption will only increase. However, even if these users exist, they can still create their own field. But users like this will be extremely rare, compared to those being hit by issues or confusion caused by the continued existence of IPAddressField. 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 django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers. For more options, visit https://groups.google.com/groups/opt_out.
