I'd like to make one more pitch for a slightly different implementation here. My concern with CompositeField isn't based on the fact that it doesn't map one-to-one with a field in the table; it's that it doesn't have any of the semantics that are associated with a field. In particular, it can't be:
- Assigned to. - Iterated over. - Or even have a value. My suggestion is to create an Index type that can be included in a class just like a field can. The example we've been using would then look like: class Foo(Model): x = models.FloatField() y = models.FloatField() a = models.ForeignKey(A) b = models.ForeignKey(B) coords = models.CompositeIndex((x, y)) pair = models.CompositeIndex((a, b), primary_key=True) We could have FieldIndex (the equivalent of the current db_index=True), CompositeIndex, and RawIndex, for things like expression indexes and other things that can be specified just as a raw SQL string. I think this is a much better contract to offer in the API than one based on field which would have to throw exceptions left and right for most of the common field operations. -- 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.
