Changes between Version 3 and Version 4 of MultipleColumnPrimaryKeys

Timestamp:

Jan 29, 2007, 1:01:42 PM (18 years ago)

Author:

maney at two14 net

Comment:

some thoughts from a user of compound keys

MultipleColumnPrimaryKeys

@@ -17 +17 @@
  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.
 
+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 = 
 
@@ -23 +29 @@
 "/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 =