Just like the In() lookup discards of None members TupleIn() should
discard tuples containing any None as NULL != NULL in SQL and the
framework expects such queries to be elided under some circumstances.
Refs #31667, #36116.
Thanks Basptise Mispelon for bisecting the regression to 626d77e.
Backport of f7f38f3a0b44d8c6d14344dae66b6ce52cd77b55 from main
Non-tuple exact and in lookups have specialized logic for subqueries that can
be adapted to properly assign select mask if unspecified and ensure the number
of involved members are matching on both side of the operator.
Backport of 41239fe34d64e801212dccaa4585e4802d0fac68 from main.
Rely on ColPairs and TupleIn which support a single column to be specified
to avoid special casing ForwardManyToOne.get_prefetch_querysets().
Thanks Jacob Walls for the report.
Backport of 626d77e52a3f247358514bcf51c761283968099c from main.
Black 23.1.0 is released which, as the first release of the year,
introduces the 2023 stable style. This incorporates most of last year's
preview style.
https://github.com/psf/black/releases/tag/23.1.0
PathInfo values are ostensibly static over the lifetime of the object
for which they're requested, so the data can be memoized, quickly
amortising the cost over the process' duration.
- Replaced datetime.utcnow() with datetime.now().
- Replaced datetime.utcfromtimestamp() with datetime.fromtimestamp().
- Replaced datetime.utctimetuple() with datetime.timetuple().
- Replaced calendar.timegm() and datetime.utctimetuple() with datetime.timestamp().
This also replaces assertQuerysetEqual() to
assertSequenceEqual()/assertCountEqual() where appropriate.
Co-authored-by: Peter Inglesby <peter.inglesby@gmail.com>
Co-authored-by: Mariusz Felisiak <felisiak.mariusz@gmail.com>
Adjusted known related objects handling of target fields which relies on
from and to_fields and has the side effect of fixing a bug bug causing
N+1 queries when using reverse foreign objects.
Thanks Carsten Fuchs for the report.
* Removed all hardcoded logic for _{fieldname}_cache.
* Added an internal API for interacting with the field values cache.
Thanks carljm and MarkusH for support.
The only reason why GenericForeignKey and GenericRelation are stored
separately inside _meta is that they need to be cloned for every model
subclass, but that's not true for any other virtual field. Actually,
it's only true for GenericRelation.
