[patch] Add support for CIDR datatype

[Rob Shakir (rob@…]

This patch extends Django to support the CIDR datatype - whilst this is native in PostgreSQL, checks that are not reliant on the database engine are performed in order to support the other database systems.

The code is at ​http://rob.sh/files/django_cidr.diff and questions/problems with the code can be addresses to me at rob@…

[Rob Shakir (rob@…]

CIDR Patch for Django

[Marc Fargas <telenieko@…>]

Maybe it could go better if it was an IPAddressField with and option "accept_cidr=True|False" if so then treat the IPAddress as a CIDR mas:
ie:

   nocidr = IPAddressField()
   cidr = IPAddressField(accept_cidr=True)

   nocidr = '192.168.0.1'
   cidr = '192.168.0.1/24'

That way there's no need to add a new field to django, and having the accept_cidr option defaulting to False would make the change totally backwards compatible hence raising the possibilities of getting the patch applied.

The only thing that would change is that with the option set to True the database column would be different (to allocate the preffix) but being False it would be the same as now.

What do you think?

[Rob Shakir (rob@…]

This sounds like a good idea - allowing for the patch to be less obtrusive, and for unecessary additional fields.

I'll produce a patch implementing this for the latest code revision, and attach it to this ticket once it has been done.

[ctdecci@…]

Replying to Marc Fargas <telenieko@telenieko.com>:

Maybe it could go better if it was an IPAddressField with and option "accept_cidr=True|False" if so then treat the IPAddress as a CIDR mas:

...

That way there's no need to add a new field to django, and having the accept_cidr option defaulting to False would make the change totally backwards compatible hence raising the possibilities of getting the patch applied.

The only thing that would change is that with the option set to True the database column would be different (to allocate the preffix) but being False it would be the same as now.

What do you think?

I just wanted to add my 2 cents, FWIW:

I'm not sure that the new field, as proposed, creates any backward compatibility issues since the IPAddress field does not change--the new field is simply an addition.

The one-to-many (and many-to-one for introspection) relationship between a field and its backend database type, based on arguments (i.e., accept_cidr) seems to create a more complex problem for creating the initial database schema. Currently, _get_sql_model_create() doesn't need to know anything about each Field child class except its class name, which it uses to look up the data type. A one-to-many relationship would require it to know something more about the class.

[Jacob]

It's now possible to ​easily create custom fields; this is a perfect candidate for that new functionality.