+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 On 25 Aug 2013 18:14, "Erik Romijn" <[email protected]> wrote: > Hi Michael, > > On Aug 25, 2013, at 6:27 PM, Michael Manfre <[email protected]> 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 [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. > -- 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.
