Opened 16 years ago

Last modified 6 weeks ago

#5929 assigned New feature

Allow Fields to use multiple db columns (complex datatypes)

Reported by: Daniel Poelzleithner Owned by: HAMA Barhamou
Component: Database layer (models, ORM) Version: dev
Severity: Normal Keywords:
Cc: Pavel Anossov, artagnon, Daniel Barreto, James Turk, glassreistor, ben.coughlan@…, ognajd@…, j.arnds@…, carlos.palol@…, cmawebsite@…, Frank Sachsenheim Triage Stage: Accepted
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no


Currently it seems that it is not possible to have complex db filds. For example:
Implementation of a IP model which actually should be a field type not a model. The implementation is not clean, because foreign key lookups for example do not work. The model maps for example:


into a complex query for a ip resisting in a network range.

Due the fact that model fields can only map to one db column, many complex data types can't be implemented. For example a ipv6 ip address which is a 128 bit value can't be handled by most db implementations of integer fields, so it has to be expanded to multiple columns plus a additional netmask column. Using varchar doesn't work because there is no way to search for network ranges or IPs in ranges, etc...
I think a field should be able to implement lookup mappings which can be overridden to implement complex datatypes as well as use multiple db fields.

Change History (30)

comment:1 Changed 16 years ago by Jim Meier <jim-django@…>

The relational db literature seems to teach me that related tables (and so related models) would seem to already be the standard way to handle complex data types. Why do you say that this IP model should be a field type rather than a model?

comment:2 Changed 16 years ago by Daniel Poelzleithner

Triage Stage: UnreviewedDesign decision needed

Let's see another example:

This Field is implemented as a Charfield which is actually not the right datatype. The right datatype would be 2 or 3 float or decimal values or a real geos point value.

First thing: I'm not sure if it is currently possible to fix the IP Model, but currently the lookups only work if you filter trough the NetworkAddress model itself, because it uses a special manager to rewrite the simplified lookup methods into real ones. Becaus this is manager specific, there is no way to make lookups through the normal ForeignKey interface. So every lookups is specific for this model. Not good.

The NetworkAddress Model is quite complex, because it implements some other required tools. But actually, the system uses ForeignKey relations to this model that really only represents a simple IP without all the blow, but blowing this table into a really hugh one. This is another point: performance. If you have some models with only a view records that has to be fast, and some with really many entries, lets say millions and you have lookups to the ip field queries are much slower than real implementations.

For me this is a point of clarity. A field implements a type of data, which will be implemented in one way or the other depending on the database backend used. Thats the sense of having a abstraction layer, and if most or non of the databases don't have a type that fits, it's still one field for me, even when the implementation of field uses more then one db field to implement a the functionality as it should. A model represents for me a more or less independent peace of informations that could be referred to, but is not essentially coupled to. It's just, that i don't feel like that it's right designed right in such cases :-)

comment:3 Changed 16 years ago by Malcolm Tredinnick

Keywords: qs-rf removed

Removing the qs-rf keyword, since this is out of scope for the SQL construction rewrite. It's something we can look at after that is completed, though.

comment:4 Changed 16 years ago by Jacob

Version: other branchSVN

comment:5 Changed 16 years ago by Jacob

Triage Stage: Design decision neededAccepted

comment:6 Changed 15 years ago by Gonzalo Saavedra

Cc: Gonzalo Saavedra added
Owner: changed from nobody to Gonzalo Saavedra
Status: newassigned

comment:7 Changed 15 years ago by Gonzalo Saavedra

Owner: Gonzalo Saavedra deleted
Status: assignednew

Oops, sorry. Didn't mean to assign this ticket, just wanted to add myself to the Cc list.

comment:8 Changed 15 years ago by Pavel Anossov

Cc: Pavel Anossov added

comment:9 Changed 15 years ago by artagnon

Cc: artagnon added

comment:10 Changed 15 years ago by Daniel Barreto

Cc: Daniel Barreto added

comment:11 Changed 14 years ago by James Turk

Cc: James Turk added

comment:12 Changed 14 years ago by Piotr Czachur

any chance it will be implemented in reasonable time?
I'm sure many users are looking forward it.

comment:13 Changed 14 years ago by None

Cc: glassreistor added

Anyone working on this?

comment:14 Changed 13 years ago by jdrago

coderanger convinced me to offer this up on github:

This appears to interact nicely with both the admin interface and South, but I defer to others on how to make this prettier.

comment:15 Changed 13 years ago by jdrago

Also, my inspiration/base code for that github posting was from dcramer's ratings system:

So if there's anything particularly clever in my gist, it is probably his idea.

comment:16 Changed 13 years ago by Gabriel Hurley

Severity: Normal
Type: New feature

comment:17 Changed 12 years ago by ben.coughlan@…

Cc: ben.coughlan@… added
Easy pickings: unset

This would 'really' simplify django support for python-money. I'd like to have a MoneyField which needs two columns, one for a Decimal value and another for a 3 character currency code.

Right now we're using the example found here but it leaves a lot to be desired regarding lookups and aggregates.

comment:18 Changed 12 years ago by Aymeric Augustin

UI/UX: unset

Change UI/UX from NULL to False.

comment:19 Changed 12 years ago by anonymous

Any update? I need pseudo-tz-aware field for date time, as anything but PostgreSQL supports timezone aware. I plan to use one column for date time and another for timezone name.

comment:21 Changed 12 years ago by Gonzalo Saavedra

Cc: Gonzalo Saavedra removed

comment:22 Changed 10 years ago by Daniel Sokolowski

Cc: ognajd@… added

comment:23 Changed 10 years ago by Jelko Arnds

Cc: j.arnds@… added

comment:24 Changed 10 years ago by Carlos Palol

Cc: carlos.palol@… added

comment:25 Changed 9 years ago by Collin Anderson

Cc: cmawebsite@… added

This should be much easier now that the _meta refactor is complete.

comment:27 Changed 5 years ago by Frank Sachsenheim

Cc: Frank Sachsenheim added

comment:28 Changed 9 months ago by HAMA Barhamou

Hi, I would like to work on this topic. Is it still relevant or not?

Last edited 9 months ago by HAMA Barhamou (previous) (diff)

comment:29 Changed 9 months ago by HAMA Barhamou

Owner: set to HAMA Barhamou
Status: newassigned

comment:30 Changed 8 months ago by Randy Giffen

Another example is a Blood Pressure field composed of 2 values that should be stored in separate db columns.

comment:31 Changed 6 weeks ago by Kound

This is also needed if you want to support a user entering a value in different units.
Required for this this plugin .

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