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


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

Legend:

Unmodified
Added
Removed
Modified
  • Ticket #34943, comment 3

    v2 v3  
    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.
     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. 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`.
Back to Top