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. |