When prefetching a set of child objects related to a set of parent
objects, we usually want to populate the relationship back from the
child to the parent to avoid a query when accessing that relationship
attribute. However, there's an edge case where the child queryset
itself specifies a prefetch back to the parent. In that case, we want
to use the prefetched relationship rather than populating the reverse
relationship from the parent.
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.
As a QuerySet resolves to Query the outer column references grouping logic
should be defined on the latter and proxied from Subquery for the cases where
get_group_by_cols is called on unresolved expressions.
Thanks Antonio Terceiro for the report and initial patch.
Having it happen at the lookup creation time ensures entry points
called before the compilation phase (e.g. get_group_by_cols) don't have
to duplicate the logic in charge of altering Query instances used as
rhs.
It also has the nice effect of reducing the amount of time the
alteration logic to once as opposed to multiple times if the queryset
is compiled more than once.
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.
This reverts commit e441847eca.
A shallow copy is not enough because querysets can be reused and
evaluated in nested nodes, which shouldn't mutate JOIN aliases.
Thanks Michal Čihař for the report.
Of the built-in backends, only Oracle treats empty strings and nulls as
equal, so avoid testing the default connection backend for
interprets_empty_strings_as_nulls if it can be established from the
lookup that it wouldn't affect the lookup instance returned. This
improves performance a small amount for most lookups being built,
because accessing the connections requires touching the thread critical
`Local` which is an expensive operation.
The functionality of updating the __dict__ was only present to allow
for pickling a Prefetch object, which is a comparably rare operation.
Forcing the __getstate__() implementation to handle it allows the
chaining operation to be slightly faster, which is much more common.
Since ManyToManyFields defined with `symmetrical=True` do not add a
related field to the target model, including a `related_name` argument
will never do what the coder likely expects. This makes including
a related_name with a symmetrical model raise a system check warning.
ticket-32983