Add support for composite fields

[Victor Porton]

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?

[Tim Graham]

It's not easy. See #373 for discussion and past attempts.

[Victor Porton]

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 necessarily primary keys).

[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.

[Victor Porton]

I have implemented it:

​https://bitbucket.org/portonv/composite-fields

Please help to improve it and then add it to Django core.

[Tim Graham]

I'll happily reopen the ticket if someone makes a serious proposal that doesn't also solve #373.