One use case for Composite Primary Keys is for setting up database partitions. In my case I am using Range-Hash partitions with the range determined by an IntegerField called "ISOweek" and the hash working off of the "id" field supplied by Django. To allow this partitioning to work, the primary key must be a composite primary key incorporating the "ISOweek" and the "id" fields. My versions of the sqlreset and reset management functions do this while also ensuring that "id" is marked as unique even though it is not the primary key. This allows a ForeignKey pointed at my partitioned model to work correctly by setting "id" as the to_field. (If "id" is not set as unique, Django and/or the database will fail in its' attempt to set up the full foreign key relationship.)
The initial version of Composite Primary Keys should not preclude this scenario, however full support for setting up and managing partitioned models need not be included at this time. (I plan to help add that later.) The interesting point is that support for related fields for the Composite Primary Key is not required in order to support this particular use case. Rock On Aug 28, 8:05 pm, "David Cramer" <[EMAIL PROTECTED]> wrote: > I'm not quite sure how that relates to Composite Primary Keys? > > A ForeignKey would point to multiple internal fields, but it should look > like it's a single field. At the same time, this would open up the > possibility for Composite Foreign Keys, which would mean it could point to > multiple public fields. > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
