| 1 | | I believe this can be re-opened since #373 didn't address this problem. Perhaps a generic `CompositeField` field could replace the `CompositePrimaryKey` field one day. The code written for #373 could be refactored and re-used here. Or maybe not? My problem with this ticket is it doesn't really describe what it wants to achieve exactly. If this is re-opened I suggest we define a clear interface and set of behaviours that `CompositeField` needs to support first. If someone could provide a strong use case for this please? I don't understand how the IP address problem is related to generic `CompositeField`s, that's a very specific use case and we already have `GenericIPAddressField`. |
| | 1 | I believe this can be re-opened since #373 didn't address this problem. Perhaps a generic `CompositeField` field could replace the `CompositePrimaryKey` field one day. The code written for #373 could be refactored and re-used here. Or maybe not? My problem with this ticket is it doesn't really describe what it wants to achieve exactly. If this is re-opened I suggest we define a clear interface and set of behaviours that `CompositeField` needs to support first. |
| | 2 | |
| | 3 | If someone could provide a strong use case for this please? I don't understand how the IP address problem is related to generic `CompositeField`s, that's a very specific use case and we already have `GenericIPAddressField`. |
| | 4 | |
| | 5 | The following could be easily achieved with minimal refactoring: |
| | 6 | |
| | 7 | {{{ |
| | 8 | class Subscription(Model): |
| | 9 | fee = CompositeField("amount", "currency") |
| | 10 | amount = IntegerField() |
| | 11 | currency = CharField(max_length=3) |
| | 12 | }}} |
| | 13 | |
| | 14 | I don't know if this would be enough to solve the problem this ticket describes though. |