Changes between Version 1 and Version 2 of Ticket #5929, comment 34
- Timestamp:
- Dec 8, 2024, 4:29:39 AM (2 weeks ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
Ticket #5929, comment 34
v1 v2 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 good use case for this please? I don't understand how the IP address problem is related to `CompositeField`s.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`.