In Query.join() the argument reuse_with_filtered_relation was used to
determine whether to use == or .equals(). As this area of code is
related to aliases, we only expect an instance of Join or BaseTable to
be provided - the only two classes that provide .equals().
In both cases, the implementations of __eq__() and equals() are based
on use of the "identity" property. __eq__() performs an isinstance()
check first, returning NotImplemented if required. BaseTable.equals()
then does a straightforward equality check on "identity". Join.equals()
is a little bit different as it skips checking the last element of the
"identity" property: filtered_relation. This was only included
previously when the with_filtered_relation argument was True, impossible
since bbf141bcdc.
Subquery deconstruction support required implementing complex and
expensive equality rules for sql.Query objects for little benefit as
the latter cannot themselves be made deconstructible to their reference
to model classes.
Making Expression @deconstructible and not BaseExpression allows
interested parties to conform to the "expression" API even if they are
not deconstructible as it's only a requirement for expressions allowed
in Model fields and meta options (e.g. constraints, indexes).
Thanks Phillip Cutter for the report.
This also fixes a performance regression in bbf141bcdc.
Thanks Zain Patel for the report and Simon Charette for reviews.
The exception introduced in 6307c3f1a1
revealed a possible data loss issue in the admin.
Regression in 3a505c70e7.
Nonlitteral right-hand-sides of lookups need to be wrapped in
parentheses to avoid operator precedence ambiguities.
Thanks Charles Lirsac for the detailed report.
This also renames the `asc` variable to `default_order`, markes the
`desc` variable as unused, fixes a typo in SQLCompiler.get_order_by()
docstring, and reorders some blocks in SQLCompiler._order_by_pairs().
This issue started manifesting itself when nesting a combined subquery
relying on exclude() since 8593e162c9 but
sql.Query.combine never properly handled subqueries outer refs in the
first place, see QuerySetBitwiseOperationTests.test_subquery_aliases()
(refs #27149).
Thanks Raffaele Salmaso for the report.
Django apps initialization to run management command triggers the admin
autodiscovery. Importing django.contrib.auth.tokens creates an instance
of PasswordResetTokenGenerator which required a SECRET_KEY.
For several management commands, the token generator is unused. It
should only complain about a missing SECRET_KEY when it is used.
This commit changes runtests.py's bisect_tests() and paired_tests() to
change settings only when necessary, namely when specific test names
aren't provided.
This was originally added to ensure that Django 2.0+ could not be
installed on Python 2.7 or earlier, in particular where the version of
pip or setuptools being used did not support the python_requires
argument.
Unfortunately, as REQUIRED_PYTHON has been bumped, this check no longer
satisfies its original purpose and could be misleading, e.g. if
REQUIRED_PYTHON is 3.8 and CURRENT_PYTHON is 3.7 it would request that
Django < 2 is installed, but there are later versions of Django that
support Python 3.7.
By the time Django 4 is released in December 2021, the python_requires
argument will have been supported for over five years, and Python 2 will
have been EOL for nearly two years, so we can remove this check.
See https://packaging.python.org/guides/distributing-packages-using-setuptools/#python-requires
