[Django] #27351: A Django field consisting of several fields
Django
----------------------------------------------+--------------------
Reporter: Victor Porton | Owner: nobody
Type: New feature | Status: new
Component: Database layer (models, ORM) | Version: 1.10
Severity: Normal | Keywords:
Triage Stage: Unreviewed | Has patch: 0
Easy pickings: 0 | UI/UX: 0
----------------------------------------------+--------------------
I want a "composite" Django fields which corresponds to two (rather than
one) database columns.
In fact the composite field should consist of two ForeignKey fields.
Otherwise it should behave like a normal field. For example it can be used
in a form to input data.
It seems that Django 1.10.1 does not support this. I may try to write a
patch. Any advice?
--
Ticket URL: <https://code.djangoproject.com/ticket/27351>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
Django
Reporter: Victor Porton | Owner: nobody
Type: New feature | Status: new
(models, ORM) |
Severity: Normal | Resolution:
Keywords: | Triage Stage:
| Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Changes (by Victor Porton):
* cc: porton@… (added)
* needs_better_patch: => 0
* needs_tests: => 0
* needs_docs: => 0
--
Ticket URL: <https://code.djangoproject.com/ticket/27351#comment:1>
Django
Reporter: Victor Porton | Owner: nobody
Component: Database layer | Version: 1.10
(models, ORM) |
Keywords: | Triage Stage:
| Unreviewed
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Changes (by Tim Graham):
* status: new => closed
* resolution: => duplicate
Comment:
It's not easy. See #373 for discussion and past attempts.
--
Ticket URL: <https://code.djangoproject.com/ticket/27351#comment:2>
Django
Reporter: Victor Porton | Owner: nobody
Type: New feature | Status: new
(models, ORM) |
Severity: Normal | Resolution:
| Unreviewed
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Changes (by Victor Porton):
* status: closed => new
* resolution: duplicate =>
Comment:
It isn't a duplicate of #373. #373 asks about multiple **primary** keys
while I ask for a field consisting of several "smaller" field (which are
not necessary primary keys).
--
Ticket URL: <https://code.djangoproject.com/ticket/27351#comment:3>
Django
Reporter: Victor Porton | Owner: nobody
Type: New feature | Status: new
(models, ORM) |
Severity: Normal | Resolution:
| Unreviewed
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Comment (by Aymeric Augustin):
#373 isn't about multiple primary keys. It's about a single primary key
that is split across several fields in the database, also called a
composite primary key. A well-designed, framework-level solution to the
problem you described would solve #373 and vice versa. So I agree with Tim
when he says it's a duplicate.
Outside of primary keys (and perhaps other relational fields, you didn't
give enough details about your use case to tell on which side it falls)
you can easily manage this at the application level: implement a read-
write property to proxy access to the underlying fields and you're done.
So the problem that needs solving in Django is composite primary keys. The
solution is to introduce a composite fields, which is what you described,
as far as I understand.
Since you asked for advice:
1. When the person who's paid to keep tabs on all development efforts
tells you where to start, pay attention instead of brushing off their
advice in less than 5 minutes, or else don't ask for advice in the first
place.
2. The order of magnitude of the work required to fix this is likely
hundred hours for an experienced contributor. If it was significantly
easier, I think it would have been done. The two GSoC devoted to this
problem didn't suffice. No offense meant, but you're talking about a well
understood problem and you don't describe it in a way that acknowledges
previous efforts in this area.
3. To tackle this, in addition to #373, everything Michal Petrucha wrote
about his GSoCs, and everything Thomas Stephenson wrote when he formalized
DEP 191, you should review related discussions on the django-developers
mailing list and figure out which parts of the design are solved and which
parts aren't, what code was written and why it couldn't be merged. The
meta refactor may help; if memory serves the interactions with composite
fields came up in the mailing-list discussions.
4. The next step would be to revise DEP 191 and post the resulting
proposal to django-developers.
5. Your description mixes up form fields and model fields. If the
difference is unclear to you, you need to familiarize yourself with the
Django code base before tackling this. If the difference is clear to you,
then you should pay attention to using accurate terms.
--
Ticket URL: <https://code.djangoproject.com/ticket/27351#comment:4>
Django
Reporter: Victor Porton | Owner: nobody
Type: New feature | Status: new
(models, ORM) |
Severity: Normal | Resolution:
| Unreviewed
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Comment (by Victor Porton):
I have implemented it:
https://bitbucket.org/portonv/composite-fields
Please help to improve it and then add it to Django core.
--
Ticket URL: <https://code.djangoproject.com/ticket/27351#comment:5>
Django
-------------------------------------+-------------------------------------
Reporter: Victor Porton | Owner: nobody
Component: Database layer | Version: 1.10
(models, ORM) |
Keywords: | Triage Stage:
| Unreviewed
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Changes (by Tim Graham):
* status: new => closed
* resolution: => duplicate
Comment:
I'll happily reopen the ticket if someone makes a serious proposal that
doesn't also solve #373.
--
Ticket URL: <https://code.djangoproject.com/ticket/27351#comment:6>