Changes between Version 4 and Version 5 of MultipleColumnPrimaryKeys


Ignore:
Timestamp:
01/29/07 13:13:46 (8 years ago)
Author:
maney
Comment:

this time I'm done editing :-)

Legend:

Unmodified
Added
Removed
Modified
  • MultipleColumnPrimaryKeys

    v4 v5  
    1919mjm: 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.
    2020
    21 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.
     21Hmmm, 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.
    2222
    23 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?
     23As 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?
    2424
    2525= Proposed Solutions =
     
    2929"/app_label/module/pk1/pk2/" -- With support for a generic view on just "/pk1/" (like the date based generic view)
    3030
    31 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.
     31mjm: 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.
    3232
    3333= Alternative methods =
     
    3737mjm: This only works when there is a non-compound unique key to use,
    3838if I understand what's being proposed here.
    39 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.
     39As 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.
    4040
    4141= Links / Notes =
Back to Top