#5929: Allow Fields to use multiple db columns (complex datatypes)
-------------------------------------+-------------------------------------
Reporter: Daniel | Owner: HAMA
Poelzleithner | Barhamou
Type: New feature | Status: closed
Component: Database layer | Version: dev
(models, ORM) |
Severity: Normal | Resolution: duplicate
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Old description:
> Currently it seems that it is not possible to have complex db filds. For
> example:
> [https://dev.leipzig.freifunk.net/trac/browser/ffsomething/branches/generic/apps/management/models.py
> 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:
> {{{
> NetworkAddress.objects.filter(ip__in="192.168.0.10/16")
> }}}
> 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.
New description:
Currently it seems that it is not possible to have complex db filds. For
example:
[https://dev.leipzig.freifunk.net/trac/browser/ffsomething/branches/generic/apps/management/models.py
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:
{{{
NetworkAddress.objects.filter(ip__in="192.168.0.10/16")
}}}
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.
--
Comment (by Csirmaz Bendegúz):
I believe this can be re-opened since #373 didn't address this problem.
Perhaps a generic `CompositeField` field could replace the
`CompositePrimaryKey` field one day. The code written for #373 could be
refactored and re-used here. Or maybe not? My problem with this ticket is
it doesn't really describe what it wants to achieve exactly. If this is
re-opened I suggest we define a clear interface and set of behaviours that
`CompositeField` needs to support first.
--
Ticket URL: <https://code.djangoproject.com/ticket/5929#comment:34>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
--
You received this message because you are subscribed to the Google Groups
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion visit
https://groups.google.com/d/msgid/django-updates/01070193a5c401df-947e8c5d-e3bc-4c04-8ef5-b032e1bf9273-000000%40eu-central-1.amazonses.com.
