Code

Changes between Version 6 and Version 7 of MultipleColumnPrimaryKeys


Ignore:
Timestamp:
07/28/08 12:04:43 (6 years ago)
Author:
julianb
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • MultipleColumnPrimaryKeys

    v6 v7  
    2626 
    2727Proposed solutions for the admin URL issue: 
    28 "/app_label/module/pk1,pk2/" -- does not support text primary keys which include a comma. 
    29 "/app_label/module/pk1/pk2/" -- With support for a generic view on just "/pk1/" (like the date based generic view) 
     28"/app_label/module/pk1,pk2/" -- ~~does not support text primary keys which include a comma.~~ URL encoding to the rescue! 
     29 
     30"/app_label/module/pk1/pk2/" -- ~~With support for a generic view on just "/pk1/" (like the date based generic view)~~ 
    3031 
    3132mjm: 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.