On 25/08/2013 11:25, Aymeric Augustin wrote:
On 18 mai 2013, at 14:07, Erik Romijn wrote:
As far as I know, IPAddressField has no current features that are not also
available in a GenericIPAddressField. Therefore, I suggest that we, some time
from now, deprecate IPAddressField, in favour of
On 25 août 2013, at 19:14, Erik Romijn wrote:
> 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.
Users with such stringent storage requirements would be better off storing IPv4
addresses as 32 bits intege
+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, "Eri
Hi Michael,
On Aug 25, 2013, at 6:27 PM, Michael Manfre 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 c
On Sun, Aug 25, 2013 at 6:13 AM, Erik Romijn wrote:
> 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 SQLi
On 18 mai 2013, at 14:07, Erik Romijn wrote:
> As far as I know, IPAddressField has no current features that are not also
> available in a GenericIPAddressField. Therefore, I suggest that we, some time
> from now, deprecate IPAddressField, in favour of GenericIPAddressField.
Yes. Having both o
Hi Michael,
On Aug 25, 2013, at 12:07 AM, Michael Manfre 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 lar
On Sunday, August 25, 2013 12:07:11 AM UTC+2, Michael Manfre 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
l mail last May, I haven't seen any opinions against
> deprecating IPAddressField, on this list or in #20439 [1].
>
> I therefore propose that we start the deprecation of IPAddressField in
> 1.7, in favour of GenericIPAddressField (which was introduced in 1.4). That
> means PendingD
ressField.
Since this initial mail last May, I haven't seen any opinions against
deprecating IPAddressField, on this list or in #20439 [1].
I therefore propose that we start the deprecation of IPAddressField in 1.7, in
favour of GenericIPAddressField (which was introduced in 1.
Hello all,
Since Django 1.4, we've added GenericIPAddressField, next to IPAddressField.
The new GenericIPAddressField supports IPv4 as well as IPv6 addresses, and does
normalisation of IPv6 addresses. It can also be configured to only accept IPv4
or IPv6 addresses.
As far as I know, IPAddressF
11 matches
Mail list logo
