#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 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 <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 https://groups.google.com/d/msgid/django-updates/065.2d38c0adf3145fcb098fb5e11c071ef8%40djangoproject.com. For more options, visit https://groups.google.com/d/optout.