Changes between Version 2 and Version 3 of Ticket #34943, comment 3
- Timestamp:
- Nov 2, 2023, 7:40:11 PM (12 months ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
Ticket #34943, comment 3
v2 v3 33 33 --- 34 34 35 My recommendation would be to introduce a `unique_constraint: str | tuple[str | Expression]` kwarg and deprecate `unique_fields`. When provided a `str` it would be a reference to a `UniqueConstraint` by `.name` and when it's a `tuple` it would be expected to be a index expression where `str` are resolved to field names. I guess the `str` -> `UniqueConstraint.name` part could be a distinct feature request .35 My recommendation would be to introduce a `unique_constraint: str | tuple[str | Expression]` kwarg and deprecate `unique_fields`. When provided a `str` it would be a reference to a `UniqueConstraint` by `.name` and when it's a `tuple` it would be expected to be a index expression where `str` are resolved to field names. I guess the `str` -> `UniqueConstraint.name` part could be a distinct feature request but it seems related to this issue given the only way Django supports creating unique constraints containing expressions is through `Meta.constaints`.