#27351: A Django field consisting of several fields
     Reporter:  Victor Porton        |                    Owner:  nobody
         Type:  New feature          |                   Status:  new
    Component:  Database layer       |                  Version:  1.10
  (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

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

 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 <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 django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
For more options, visit https://groups.google.com/d/optout.

Reply via email to