| Version 4 (modified by , 18 years ago) ( diff ) |
|---|
Multi-Column Primary Key support
Currently 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.
Current Status
Ticket 373: Add support for multiple-column primary keys Progress is stalled as there has been insufficient design discussion as to how this might be implemented.
Major Issues
Taken from Jacob's comment on Ticket 373 There are three basic problems in dealing with composite primary keys in Django.
- 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.
- 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.
- 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.
mjm: I'm not very familiar with Django's internals, but I suspect the first point's answer lies somewhere near the observation that a CK needs a compound data structure. In Python the obvious choices are a tuple (or list, probably interchangeably) or a dictionary. I've actually used sequences; the obvious drawback is that they require an agreed-upon convention as to the order of the components. If I were doing it over again I would give very serious thought to using mappings, at least for things that hold key values.
Hmmm, that handwaving seems to be all I have to asy about #2 as well. Not sure just how that can not break some code, though. In my work using sequences I chose - not without some pain - to make all keys sequences (and all keys' names were sequences, too). This is at least consistent, and the changes were straightforward. The fact that strings are themselves sequences actually made it more difficult, since overlooked cases would (often) misbehave rather than tossing an exception immediately - a point in favor of using mappings, maybe.
As for #3, obviously a choice has to be made, and some pathological existing cases will change. I wouldn't call the result "broken", since only hand-generated admin URLs would have a problem (well, bookmarked ones, it occurs to me, if anyone actually does that). Is anyone really concerned about making admin URLs slightly less easily hand-generatable?
Proposed Solutions
Proposed solutions for the admin URL issue: "/app_label/module/pk1,pk2/" -- does not support text primary keys which include a comma. "/app_label/module/pk1/pk2/" -- With support for a generic view on just "/pk1/" (like the date based generic view)
mjm: From Adrian's remark about how greedy the admin URL matching is, I take it that the entire tail is taken to be the key matter. That doesn't change: the admin code decides how it will recognize key part boundaries, and it generates URLs that it will recognize. The discussion about allowing a partial key spec to select a set (rather than a single record) seems to me a diversion at this level. It does point out a [some?] non-unique selection criteria that might be especially useful to have supported automatically.
Alternative methods
Currently, 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?)
mjm: This only works when there is a non-compound unique key to use, if I understand what's being proposed here. As such, it may be workable as a way to squeeze a design that naturally has CKs into Django, but it's of no use for workign with an existing schema that has only the CK.
Links / Notes
http://code.djangoproject.com/ticket/373 Rails/ActiveRecord doesn't support this natively, but http://compositekeys.rubyforge.org/ is an add-on which does