Changes between Version 3 and Version 4 of Ticket #34943, comment 3


Ignore:
Timestamp:
Nov 2, 2023, 7:40:58 PM (7 months ago)
Author:
Simon Charette

Legend:

Unmodified
Added
Removed
Modified
  • Ticket #34943, comment 3

    v3 v4  
    3333---
    3434
    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`.
     35My 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.
     36
     37I 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 composed of expressions is through `Meta.constaints` and having to define the exact expression twice is error prone.
Back to Top