Opened 18 years ago

Closed 16 years ago

#1636 closed enhancement (wontfix)

[patch] Add support for CIDR datatype

Reported by: Rob Shakir (rob@… Owned by: nobody
Component: Database layer (models, ORM) Version:
Severity: minor Keywords:
Cc: rob@… Triage Stage: Design decision needed
Has patch: yes Needs documentation: no
Needs tests: no Patch needs improvement: yes
Easy pickings: no UI/UX: no

Description

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@…

Attachments (1)

django_cidr.diff (6.1 KB ) - added by Rob Shakir (rob@… 18 years ago.
CIDR Patch for Django

Download all attachments as: .zip

Change History (7)

by Rob Shakir (rob@…, 18 years ago

Attachment: django_cidr.diff added

CIDR Patch for Django

comment:1 by Adrian Holovaty, 18 years ago

priority: normallow
Severity: normalminor

comment:2 by Adrian Holovaty, 17 years ago

Summary: [PATCH] Add support for CIDR datatype[patch] Add support for CIDR datatype

comment:3 by Marc Fargas <telenieko@…>, 17 years ago

Patch needs improvement: set
Triage Stage: UnreviewedDesign decision needed

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?

comment:4 by Rob Shakir (rob@…, 17 years ago

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.

in reply to:  3 comment:5 by ctdecci@…, 17 years ago

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.

comment:6 by Jacob, 16 years ago

Resolution: wontfix
Status: newclosed

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

Note: See TracTickets for help on using tickets.
Back to Top