Changes between Version 11 and Version 12 of MultipleColumnPrimaryKeys


Ignore:
Timestamp:
Apr 2, 2009, 5:47:11 PM (16 years ago)
Author:
Tobu
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • MultipleColumnPrimaryKeys

    v11 v12  
    3737= Alternative methods =
    3838
    39 Currently, you can "fake" it by declaring one of the keys to be primary in Django and adding a unique constraint to the model. (needs more info...examples?)
    40 
    41 mjm: This only works when there is a non-compound unique key to use,
    42 if I understand what's being proposed here.
    43 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.
    44 
    45 It can be done using unique-together. ~djansoft
     39 * notnotpeter: Currently, you can "fake" it by declaring one of the keys to be primary in Django and adding a unique constraint to the model. (needs more info...examples?)
     40 * 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.
     41 * 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.
    4643
    4744= Links / Notes =
Back to Top