Changes between Version 13 and Version 14 of MultipleColumnPrimaryKeys
- Timestamp:
- Aug 18, 2009, 12:05:55 AM (15 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
MultipleColumnPrimaryKeys
v13 v14 41 41 * djansoft: It can be done using unique-together. 42 42 * 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 44 44 45 = Links / Notes =