Comment (by Mariusz Felisiak):
As a workaround you can use `fields` instead of `*expressions`, e.g.
{{{
UniqueConstraint(fields=["poet", "name"],
name="unique_together_poet_name")
}}}
--
Ticket URL: <https://code.djangoproject.com/ticket/34296#comment:3>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
Comment (by Jannis Vajen):
Thank you, Mariusz. Using `fields=[]` works as expected.
If `UniqueConstraints` with `expressions` are excluded from validation on
purpose, I wonder if this should be mentioned in the docs. It seems to me
that the admonition you added in #33335
> **Validation of Constraints**
>
> In general constraints are not checked during full_clean(), and do not
raise ValidationErrors. Rather you’ll get a database integrity error on
save(). UniqueConstraints without a condition (i.e. non-partial unique
constraints) and expressions (i.e. non-functional unique constraints) are
different in this regard, in that they leverage the existing
validate_unique() logic, and thus enable two-stage validation. In addition
to IntegrityError on save(), ValidationError is also raised during model
validation when the UniqueConstraint is violated.
still fully applies in 4.1, 4.2, and dev and should not have been removed
during #30581
> **Validation of Constraints**
>
> Constraints are checked during the model validation.
Do you agree, or am I overlooking something?
--
Ticket URL: <https://code.djangoproject.com/ticket/34296#comment:4>