IPAddressField

[Gregor Kling]

Hello there,

Regrettably the IPAddressField implementation is not what I expect :-(.
Is there by any chance, the possibilty to have a solution that works for
ipv4 *and* ipv6 in the near future ?

I know you have tons of things to do before the release of the
outstanding 1.1.

So far, I do have very scarce knowledge of the underlying framework
(quiet in fact none at all), but from what I see now, this can't be
that challenging. Feel free to correct me ;-)

First of all I would use a normal unsigned integer in all backends and
let IPy do the *math*.

In django/forms/fields.py I would rename ipv4_re to ip_re with the
following modifications for the beginning:
re.compile(r'^(25[0-5]|2[0-4]\d|[0-1]?\d?\d)(\.(25[0-5]|2[0-4]\d|[0-1]?\d?\d)){3}|([:0-9a-fA-F]+)$')

Then I would add a clean method that uses IPy to check vor a valid
ip-address, never mind the version.
def clean(self, value):
if self.required and not value:
raise ValidationError(self.error_messages['required'])
...
try:
IPy.IP(value)
except ValueError:
raise ValidationError(self.error_messages['...'] % {...})

In django/db/models/fields/__init__.py it seems that I have to use the
to_python method to do the checks....
And surely get rid of the kwargs['max_length'] = 15 assignment.
return new_value

So the IPAddressField would not change, maybe it would be useful to have
a member that gives the answer which ip version is used.

gfk

[Ian Kelly]

On Fri, Mar 13, 2009 at 1:58 PM, Gregor Kling
<gregor...@dvz.fh-giessen.de> wrote:
>
> Hello there,
>
> Regrettably the IPAddressField implementation is not what I expect :-(.
> Is there by any chance, the possibilty to have a solution that works for
> ipv4 *and* ipv6  in the near future ?

See ticket #811: http://code.djangoproject.com/ticket/811

Regards,
Ian

[Gregor Kling]

Hello,
Ian Kelly schrieb:

Hm, thanks for the link Ian.
But I have some problems to understand the actual state of the patch.
It is not yet in the trunk right now. So will it make it in 1.1 ?

Barring the actual state, I do not have a good feeling about this patch.
Foremost, I think IPy really should be used, last but not lease to
follow DRY.

From a design point of view, I think the IPAddressField should rule all
ip versions.
Certainly it is not a bad idea, to have IPv4 and IPv6 versions of this
field.

gfk

[Adi Sieker]

Hi,

The way I read the comments on the ticket the last patch supports IPv4 and IPv6 address.

See: http://code.djangoproject.com/ticket/811#comment:16

adi

[Gregor Kling]

Hello,

> The way I read the comments on the ticket the last patch supports IPv4
> and IPv6 address.
> See: http://code.djangoproject.com/ticket/811#comment:16

Adi, if you mean this:
* attachment ipv6-9781.diff added.
IPv6 patch for trunk, revision 9781
yes you are right, there was added an IP6AddressField that handles the
ipv6 stuff.
The existing IPAddressField further on cares about the IPv4.

But that was exactly my point. It should be possible to let the
IPAddressField handle any version, and to have specific
AddressFields for the varying versions.

Beyond that, the arguments of using IPy, and using an positive int in
the backends are still there.

gfk

[Adi Sieker]

Hi,

On 14.03.2009, at 19:22, Gregor Kling wrote:

Hello,

The way I read the comments on the ticket the last patch supports IPv4

and IPv6 address.

See: http://code.djangoproject.com/ticket/811#comment:16

Adi, if you mean this:
       *  attachment ipv6-9781.diff added.
           IPv6 patch for trunk, revision 9781
yes you are right, there was added an IP6AddressField that handles the
ipv6 stuff.
The existing IPAddressField further on cares about the IPv4.

The IP6AddressField also handles IPv4 addresses, as mentioned in the docs section of the patch.

+.. class:: IP6AddressField([**options])

+

+An IPv4 or IPv6 address, in string format (e.g. "192.0.2.30" or 

+"2a01:5d8:25ae:9451:20d:39bc:1e6:cab:b2c"). The admin represents this as an 

+``<input type="text">`` (a single-line input).

and I guess the IPAddressField didn't get changed because the IPv6 addresses need a longer database field,

so changing the IPAddressField would break backward compatibility.

adi

[Gregor Kling]

Adi Sieker schrieb:

>
> The IP6AddressField also handles IPv4 addresses, as mentioned in the
> docs section of the patch.
>
> +.. class:: IP6AddressField([**options])
> +
> +An IPv4 or IPv6 address, in string format (e.g. "192.0.2.30" or
> +"2a01:5d8:25ae:9451:20d:39bc:1e6:cab:b2c"). The admin represents this
> as an
> +``<input type="text">`` (a single-line input).
>
>

Yes,shame on me, this one I overlooked.

> and I guess the IPAddressField didn't get changed because the IPv6
> addresses need a longer database field,
> so changing the IPAddressField would break backward compatibility.

Generally i do agree with the *usefulness* of not breaking compatibiltiy.
But on the other hand, I think that correcting this weird handling of IP
addresses would legitimate the cut.
Because the handling of IP addresses is not that intrinsic, like for
example the orm, it should be possible to cope with the change,
and to get rid of this ward.

gfk

[pavel.schon]

Hi, I'v written IPAddressField that stores IPy.IP instances. Look at
http://www.djangosnippets.org/snippets/1381/ and try it. Thanks for
bugreports.

[Ian Kelly]

I'm afraid Oracle only supports 38 digits of precision for numeric
columns. Since this requires 39, it won't work.

Thanks,
Ian

[Malcolm Tredinnick]

On Mon, 2009-03-16 at 13:18 +0100, Gregor Kling wrote:
[...]

> Generally i do agree with the *usefulness* of not breaking compatibiltiy.
> But on the other hand, I think that correcting this weird handling of IP
> addresses would legitimate the cut.
> Because the handling of IP addresses is not that intrinsic, like for
> example the orm, it should be possible to cope with the change,
> and to get rid of this ward.

Right now we have an IPAddress field. People are using it. You *cannot*
break their code and requiring the database field to be changed does
just that. So, no. This would have to be a differently named field. We
might well deprecate the existing version, but breaking existing code
just because it's "neat" is not an option.

Regards,
Malcolm