When Expression.__init__() overrides make use of *args, **kwargs
captures their argument values are respectively bound as a tuple and
dict instances. These composite values might themselves contain values
that require special identity treatments such as Concat(output_field)
as it's a Field instance.
Refs #30628 which introduced bound Field differentiation but lacked
argument captures handling.
Thanks erchenstein for the report.
Backport of df2c4952df6d93c575fb8a3c853dc9d4c2449f36 from main
In order for Expression.relabeled_clone to work appropriately its
get_source_expressions method must return all resolvable which wasn't the case
for Lookup when its right-hand-side is "direct" (not a compilable).
While refs #22288 added support for non-literals iterable right-hand-side
lookups it predated the subclassing of Lookup(Expression) refs #27021 which
could have been an opportunity to ensure right-hand-sides are always resolvable
(ValueList and ExpressionList).
Addressing all edge case with non-resolvable right-hand-sides would require
a significant refactor and deprecation of some parts of the Lookup interface so
this patch only focuses on FieldGetDbPrepValueIterableMixin (In and Range
lookups) by making sure that a right-hand-side containing resolvables are dealt
with appropriately during the resolving phase.
Thanks Aashay Amballi for the report.
Backport of 089deb82b9ac2d002af36fd36f288368cdac4b53 from main.
This also caused un-ordered sliced prefetches to crash as they rely on Window.
Regression in e16d0c176e9b89628cdec5e58c418378c4a2436a that made OrderByList
piggy-back ExpressionList without porting the empty handling that the latter
provided.
Supporting explicit empty ordering on Window functions and slicing is arguably
a foot-gun design due to how backends will return undeterministic results but
this is a problem that requires a larger discussion.
Refs #35064.
Thanks Andrew Backer for the report and Mariusz for the review.
This also introduces Expression.constraint_validation_compatible that
allows specifying that expression should be ignored during a constraint
validation.
Also removed tests that ensured that adapt_(date)timefield backend
operations where able to deal with expressions when it's not the case
for any other adapt methods.
Thanks Splunk team: Preston Elder, Jacob Davis, Jacob Moore,
Matt Hanson, David Briggs, and a security researcher: Danylo Dmytriiev
(DDV_UA) for the report.
This includes refactoring of CombinedExpression._resolve_output_field()
so it no longer uses the behavior inherited from Expression of guessing
same output type if argument types match, and instead we explicitly
define the output type of all supported operations.
This also makes nonsensical operations involving dates
(e.g. date + date) raise a FieldError, and adds support for
automatically inferring output_field for cases such as:
* date - date
* date + duration
* date - duration
* time + duration
* time - time
In these cases Black produces unexpected results, e.g.
def make_random_password(
self,
length=10,
allowed_chars='abcdefghjkmnpqrstuvwxyz' 'ABCDEFGHJKLMNPQRSTUVWXYZ' '23456789',
):
or
cursor.execute("""
SELECT ...
""",
[table name],
)
This brings the behaviour in line with Field subclasses which append to
the validators within __init__(), like BinaryField, and prevents the
creation of a validator which incorrectly throws a TypeError, if it
were used.
