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
.
The following could be easily achieved with minimal refactoring:
class Subscription(Model):
fee = CompositeField("amount", "currency")
amount = IntegerField()
currency = CharField(max_length=3)
I don't know if this would be enough to solve the problem this ticket describes though or if you had something else in mind.