+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" <erom...@solidlinks.nl> wrote: > 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. > -- 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.
