Code

Opened 8 years ago

Closed 6 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: UI/UX:

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@… 8 years ago.
CIDR Patch for Django

Download all attachments as: .zip

Change History (7)

Changed 8 years ago by Rob Shakir (rob@…

CIDR Patch for Django

comment:1 Changed 8 years ago by adrian

  • priority changed from normal to low
  • Severity changed from normal to minor

comment:2 Changed 7 years ago by adrian

  • Summary changed from [PATCH] Add support for CIDR datatype to [patch] Add support for CIDR datatype

comment:3 follow-up: Changed 7 years ago by Marc Fargas <telenieko@…>

  • Patch needs improvement set
  • Triage Stage changed from Unreviewed to Design 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 Changed 7 years ago by 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.

comment:5 in reply to: ↑ 3 Changed 7 years ago by 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.

comment:6 Changed 6 years ago by jacob

  • Resolution set to wontfix
  • Status changed from new to closed

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

Add Comment

Modify Ticket

Change Properties
<Author field>
Action
as closed
as The resolution will be set. Next status will be 'closed'
The resolution will be deleted. Next status will be 'new'
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.