Code

Changes between Version 14 and Version 15 of MultipleColumnPrimaryKeys


Ignore:
Timestamp:
08/17/09 22:07:22 (5 years ago)
Author:
toszter@…
Comment:

Edited the solution proposed

Legend:

Unmodified
Added
Removed
Modified
  • MultipleColumnPrimaryKeys

    v14 v15  
    4141 * djansoft: It can be done using unique-together. 
    4242 * Tobu: You can't use just one key. A use case for illustration: a NamespacedTag model with a CK made of a namespace and a name. The primary key can't be just the namespace or just the name since that would be ambiguous. The only solution (and I dislike it since it is bad modelling and forces database accesses to be serialized on a counter) is to use an AutoField. 
    43  * toszter: Call me nutty, but why not declare any number of columns as primary key in your model field, then create a "hidden" pk_composite column that's just a hash of the three pk values in the row?  When you do a lookup on a pk, you assume the ENTIRE combination of values is the primary key, nothing more or less. So when you look up according to the values needed to create the full pk_composite, the hash always computes and if the hash algorithm is public, can be used off the URL, the querystring in db lookups, and just about anywhere.  Seems pretty simple in my mind but then again I am not going into great detail here. 
     43 * toszter: Call me nutty, but why not declare any number of columns as primary key in your model, which django then uses to create a "hidden" pk_composite column that's just a hash of the three pk values in the row?  When you do a lookup on a pk, you assume the ENTIRE combination of values is the primary key, nothing more or less. So when you look up according to the values needed to create the full pk_composite, the hash always computes and if the hash algorithm is public, can be used off the URL, the querystring in db lookups, and just about anywhere.  Seems pretty simple in my mind but then again I am not going into great detail here. 
    4444 
    4545= Links / Notes =