Changes between Version 12 and Version 13 of MultipleColumnPrimaryKeys


Ignore:
Timestamp:
Apr 2, 2009, 5:48:17 PM (15 years ago)
Author:
Tobu
Comment:

typo

Legend:

Unmodified
Added
Removed
Modified
  • MultipleColumnPrimaryKeys

    v12 v13  
    4040 * 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 working with an existing schema that has only the CK.
    4141 * djansoft: It can be done using unique-together.
    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 force database accesses to be serialized on a counter) is to use an AutoField.
     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.
    4343
    4444= Links / Notes =
Back to Top