Changes between Initial Version and Version 1 of MultipleColumnPrimaryKeys


Ignore:
Timestamp:
01/27/2007 08:52:42 PM (13 years ago)
Author:
notnotpeter <petertripp@…>
Comment:

Created page. 1st revision.

Legend:

Unmodified
Added
Removed
Modified
  • MultipleColumnPrimaryKeys

    v1 v1  
     1= Multi-Column Primary Key support =
     2
     3Currently Django models only support single column primary keys.  Support for multi-column primary keys would allow Django to better integrate with legacy databases (whose schema cannot be changed and have multi-column primary keys).  There are a lot of details to get right here, but done right, it would allow for more flexibility in data modeling.
     4
     5= Current Status =
     6[http://code.djangoproject.com/ticket/373 Ticket 373: Add support for multiple-column primary keys]
     7Progress is stalled as there has been insufficient design discussion as to how this might be implemented.
     8
     9= Major Issues
     10Taken from [http://code.djangoproject.com/ticket/373#comment:3 Jacob's comment on Ticket 373]
     11There are three basic problems in dealing with composite primary keys in Django.
     12
     13 1. A number of APIs use "obj._meta.pk" to access the primary key field (for example, to do "pk=whatever" lookups). A composite PK implementation would need to emulate this in some way to avoid breaking everything.
     14 2. A number of things use (content_type_id, object_pk) tuples to refer to some object -- look at the comment framework, or the admin log API. Again, a composite PK system would need to somehow not break this.
     15 3. Admin URLs; they're of the form "/app_label/module_name/pk/"; there would need to be a way to map URLs to objects in the absence of a primary key.
     16
     17= Proposed Solutions =
     18Proposed solutions for the admin URL issue:
     19"/app_label/module/pk1,pk2/" -- does not support text primary keys which include a comma.
     20"/app_label/module/pk1/pk2/" -- With support for a generic view on just "/pk1/" (like the date based generic view)
     21
     22= Alternative methods =
     23Currently, you can "fake" it by declaring one of the keys to be primary in Django and adding a unique constraint to the model. (needs more info...examples?)
     24
     25= Links / Notes=
     26[http://code.djangoproject.com/ticket/373]
     27Rails/ActiveRecord doesn't support this natively, but [http://compositekeys.rubyforge.org/] is an add-on which does
Back to Top