On Wed, Mar 16, 2011 at 4:24 AM, Johannes Dollinger <emulb...@googlemail.com> wrote: > I would be nice if support for composite primary keys would be implemented as > a special case of general composite fields. There would be no need for new > Meta options: > > class Foo(Model): > x = models.FloatField() > y = models.FloatField() > coords = models.CompositeField((x, y), db_index=True) > a = models.ForeignKey(A) > b = models.ForeignKey(B) > pair = models.CompositeField((a, b), primary_key=True) > > A CompositeField descriptor would then return a namedtuple of its values and > would support queries: > > filter(coords__x=42) > filter(coords=(1,2)) > > Adding the individual fields may be optional, e.g, > CompositeField((FloatField(), FloatField()), db_index=True). > > This has been proposed before: > http://groups.google.com/group/django-developers/browse_thread/thread/32f861c8bd5366a5
I like this quite a bit. Of all the various syntaxes proposed here so far, this is the first one that feels like it "fits" with the rest of Django, and the first one I'm +1 on. I'm sensitive to Christophe's point that a "composite field" doesn't map to a relational concept very well, but quite frankly that ship has sailed. We've got ManyToManyFields, GenericForeignKeys, and once you branch out into the ecosystem you find TagFields, PickleFields (ugh) and so forth. Jacob -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
