#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
-------------------------------------+-------------------------------------
Comment (by Simon Charette):
> 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.
In my opinion this ticket would be a good ''home'' for the
[https://github.com/django/django/pull/17279 the work that Lily started]
around generic composite fields and that you validated and specialized
around primary keys support at first. Being able to define fields that are
composed of other fields is not only useful from a model definition
perspective, as referenced in this ticket, but it's also an important part
missing in the ORM to represent functions that return rows.
There are a few instances in the ORM resolving logic where subqueries and
set-returning functions are special cased by instance type checks due to
the impossibility of representing their `output_field` as a
`CompositeField`. For example, `Author.objects.values("id", "name")`
[https://github.com/django/django/blob/c075d4c2c8cef3c9b28180c749d421c63544a9dd/django/db/models/sql/query.py#L321-L327
fakes] its `output_field` to the one associated with `id` instead of
simply being `CompositeField(IntegerField(name="id"),
CharField(name="name"))`.
From working on a few features/bugs that relate to subquery resolving and
fiddling with aggregation though subquery (#28296), composite queries
(`UNION` and friends), subquery annotations with multiple columns
(#33706), and implicit wrapping of a subquery I can tell you that being
able to use `CompositeField` as any `Expression.output_field` and have
good support for it internally would simplify many of these problems.
If only for internal usage at first I think it would be worth adding.
> I don't understand how the IP address problem is related to generic
CompositeFields, that's a very specific use case and we already have
GenericIPAddressField.
This ticket was created 17 years ago and at that time there was no
`GenericIPAddressField`
([https://docs.djangoproject.com/en/stable/releases/1.4/#extended-
ipv6-support added in 1.4 released in 2012]), no support for custom
lookups and transforms or expressions of any form, nor migrations, and
custom fields support was also limited. Today what was initially requested
in this ticket can be implemented with custom lookups and would be greatly
simplified by the usage of the `inet` type on Postgres.
--
Ticket URL: <https://code.djangoproject.com/ticket/5929#comment:35>
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/01070193a73ef94c-45741d29-2522-4c44-a3d5-56c4efd04f5b-000000%40eu-central-1.amazonses.com.
