Changes between Version 4 and Version 5 of MultipleColumnPrimaryKeys

Timestamp:

Jan 29, 2007, 1:13:46 PM (18 years ago)

Author:

maney

Comment:

this time I'm done editing :-)

MultipleColumnPrimaryKeys

@@ -19 +19 @@
 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.
+Hmmm, that handwaving seems to much of what I have to say about the second point 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 be 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?
+As for the last item, obviously a choice has to be made, and some 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 = 
@@ -29 +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.
+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.  This wouldn't change: the admin code decides how it will recognize key part boundaries, and it generates URLs that conform to that.  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.  I would expect a selection based on matching one (or some) of a CK's columns to look the same as if that selection were configured for non-PK column(s), I think.
 
 = Alternative methods = 
@@ -37 +37 @@
 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.
+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 working with an existing schema that has only the CK.
 
 = Links / Notes =