The "data in self.children" branch was causing data.__eq__ to be
called for each entries in "self.children" which resulted in a huge
slowdown during queryset construction.
It's purpose was to prevent queries of the form
Model.objects.filter(foo='bar').filter(foo='bar')
from resulting in
WHERE foo='bar' AND foo='bar'
but it's not covered by the suite and has arguable performance benefits
since it's not very common and SQL engines are usually very good at
folding/optimizing these.
See also #32632 for prior discussion around comparing data to the
Node's children.
Co-authored-by: Nick Pope <nick@nickpope.me.uk>
Address a long standing bug in a Where.add optimization to discard
equal nodes that was surfaced by implementing equality for Lookup
instances in bbf141bcdc.
Thanks Shaheed Haque for the report.
While Node class has a useful `__str__`, its `__repr__` is not that
useful. Added a `__repr__` that makes use of the current `__str__`.
This is especially useful since the more popular `Q` class inherits
`tree.Node`. Also created new tests that cover most of `Node` class
functionality.
The sql/query.py add_q method did a lot of where/having tree hacking to
get complex queries to work correctly. The logic was refactored so that
it should be simpler to understand. The new logic should also produce
leaner WHERE conditions.
The changes cascade somewhat, as some other parts of Django (like
add_filter() and WhereNode) expect boolean trees in certain format or
they fail to work. So to fix the add_q() one must fix utils/tree.py,
some things in add_filter(), WhereNode and so on.
This commit also fixed add_filter to see negate clauses up the path.
A query like .exclude(Q(reversefk__in=a_list)) didn't work similarly to
.filter(~Q(reversefk__in=a_list)). The reason for this is that only
the immediate parent negate clauses were seen by add_filter, and thus a
tree like AND: (NOT AND: (AND: condition)) will not be handled
correctly, as there is one intermediary AND node in the tree. The
example tree is generated by .exclude(~Q(reversefk__in=a_list)).
Still, aggregation lost connectors in OR cases, and F() objects and
aggregates in same filter clause caused GROUP BY problems on some
databases.
Fixed#17600, fixed#13198, fixed#17025, fixed#17000, fixed#11293.
This removes some of the leaky abstraction problems (lifting WhereNode
internals into the Query class) from that commit and makes it possible for
extensions to WhereNode to have access to the field instances. It's also
backwards-compatible with pre-[7773] code, which is also better.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@7835 bcc190cf-cafb-0310-a4f2-bffc1f526a37
django-bot
Keryn Knight
Nick Pope
Simon Charette
aspalding
Sergey Fedoseev
Mariusz Felisiak
Mads Jensen
Ian Foote
Anton Samarchyan
Claude Paroz
Simon Charette
Tim Graham
Jon Dufresne
Moayad Mardini
xuxiang
Alex Gaynor
Aymeric Augustin
Anssi Kääriäinen
Adrian Holovaty
Jacob Kaplan-Moss
Malcolm Tredinnick