On Mar 16, 11:43 am, Christophe Pettus <x...@thebuild.com> wrote: > On Mar 16, 2011, at 2:24 AM, Johannes Dollinger wrote: > > > I would be nice if support for composite primary keys would be implemented > > as a special case of general composite fields. > > It's appealing, but the reality is that no existing back-end actually has > such an animal as a composite field. In all of these cases, what we're > really creating is a composite index on a set of standard fields. > Introducing a more powerful index-creation syntax into Django isn't a bad > idea, but we shouldn't call it a "field" if it is not.
I'm not expressing an opinion one way or another on composite primary key syntax, but I don't agree here that a Django model "field" must map one-to-one to a database column. It already does not, in the case of ManyToManyField, and at some point I would like to introduce (irrespective of composite primary keys) a more general ORM abstraction for composite fields (i.e. model Fields that map to more than one database column) as a path to cleaning up the implementation of GenericForeignKey. Carl -- 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.
