On Thu, 2008-11-13 at 10:53 -0800, David Cramer wrote: > Here's my proposal for the composite keys (which act much like generic > keys except more useful): > > class MyModel2: > pass > > class MyModel3: > pk_part1 = models.AutoField() > pk_part2 = models.ForeignKey(MyModel2) > name = models.TextField() > > class MyModel: > pk_part1 = models.IntegerField() > pk_part2 = models.ForeignKey(MyModel2) > > mymodel3 = models.CompositeForeignKey(MyModel3, pk_part1=pk_part1, > pk_part2=pk_part2)
Why is the primary key specified on the relation field, rather than just being part of MyModel3? A model has a primary key, and the foreign relation should use that in the natural case. It's not a property of the relation, it's a property of the target model and should be declared there. There might be an argument for a multi-column version of to-field, but a tuple or list would seem the easiest way of specifying that, rather than a variable number of arguments. At that point, I think normal ForeignKey fields could be adjusted to Just Work(tm), since they'll know they're related to a model with a multi-column primary key. Regards, Malcolm --~--~---------~--~----~------------~-------~--~----~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~----------~----~----~----~------~----~------~--~---
