This is the exact same issue as refs #30408 but for creating a model with a
constraint containing % escapes instead of column addition. All of these issues
stem from a lack of SQL and parameters separation from the BaseConstraint DDL
generating methods preventing them from being mixed with other parts of the
schema alteration logic that do make use of parametrization on some backends
(e.g. Postgres, MySQL for DEFAULT).
Prior to the addition of Field.db_default and GeneratedField in 5.0
parametrization of DDL was never exercised on model creation so this is
effectively a bug with db_default as the GeneratedField case was addressed by
refs #35336.
Thanks Julien Chaumont for the report and Mariusz Felisiak for the review.
Partially reverts 0b33a3abc2.
Storage.exists(name) was documented to "return False if
the name is available for a new file." but return True if
the file exists. This is ambiguous in the overwrite file
case. It will now always return whether the file exists.
Thank you to Natalia Bidart and Josh Schneier for the
review.
While refs #34125 focused on the SQL correctness of slicing of union of
potentially empty queries it missed an optimization opportunity to avoid
performing a query at all when all queries are empty.
Thanks Lucidiot for the report.
The original tests required the creation of a model that is no longer necessary
and were exercising Model.full_clean(validate_constraints) which has nothing
to do with the nulls_distinct feature.
The logic allowing UniqueConstraint(fields).validate to preserve backward
compatiblity with Model.unique_error_message failed to account for cases where
the constraint might not be attached to a model which is a common pattern
during testing.
This changes allows for arbitrary UniqueConstraint(fields) to be tested in
isolation without requiring actual models backing them up.
Co-authored-by: Mark G <mark.gensler@protonmail.com>
It was added in 01d440fa1e to
prevent "RuntimeError: OrderedDict mutated during iteration".
That particular issue was fixed in d660cee5bc
but the issue could remain in Join.as_sql() subclasses.
Co-authored-by: Simon Charette <charette.s@gmail.com>
Fixed a regression which would cause multiple To, Cc, and
Reply-To headers in the result of EmailMessage.message() if
values were supplied for both to/cc/reply_to and the
corresponding extra_headers fields.
Updated related tests to check the generated message() has
exactly one of each expected header using get_all().
Regression in b03d500295.
