| Age | Commit message (Collapse) | Author |
|---|
|
Node.create() which has a compatible signature with Node.__init__()
takes in a single `children` argument rather than relying in unpacking
*args in Q.__init__() which calls Node.__init__().
In addition, we were often needing to unpack iterables into *args and
can instead pass a list direct to Node.create().
|
|
This allows the copy.copy() usage in the Q._combine() method to finish
sooner, instead of having to fallback to using the __reduce_ex__(4)
method.
Thia also avoids having to fall into copy.copy() at in Q._combine(),
when combining a Q() with another Q().
Co-authored-by: Keryn Knight <keryn@kerynknight.com>
|
|
We can use copy() in Node.add() instead of create() as we don't need the
children to be cloned via [:] subscript in __init__().
|
|
Node._new_instance() was added in
6dd2b5468fa275d53aa60fdcaff8c28bdc5e9c25 to work around Q.__init__()
having an incompatible signature with Node.__init__().
It was intended as a hook that could be overridden if subclasses needed
to change the behaviour of instantiation of their specialised form of
Node. In practice this doesn't ever seem to have been used for this
purpose and there are very few calls to Node._new_instance() with other
code, e.g. Node.__deepcopy__() calling Node and overriding __class__ as
required.
Rename this to Node.create() to make it a more "official" piece of
private API that we can use to simplify a lot of other areas internally.
The docstring and nearby comment have been reworded to read more
clearly.
|
|
|
|
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>
|
|
Unused since its introduction in d3f00bd5706b35961390d3814dd7e322ead3a9a3.
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 bbf141bcdc31f1324048af9233583a523ac54c94.
Thanks Shaheed Haque for the report.
|
|
lists.
Regression in fc6528b25ab1834be1a478b405bf8f7ec5cf860c.
|
|
|
|
lists.
Regression in fc6528b25ab1834be1a478b405bf8f7ec5cf860c.
|
|
|
|
Regression in 508b5debfb16843a8443ebac82c1fb91f15da687 which
added Node.__eq__().
|
|
|
|
|
|
|
|
Thanks Tim Graham for the review.
|
|
|
|
Thanks Tim for the review.
|
|
|
|
|
|
Thanks Ben Kraft for the report, and Simon Charette for the review.
|
|
|
|
comprehension
|
|
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.
|
|
|
|
|
|
Thanks Lennart Regebro for pointing it out.
|
|
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.
|
|
for Python 2 object model compatibility methods.
|
|
This reverts commit 28abf5f0ebc9d380f25dd278d7ef4642c4504545.
Conflicts:
docs/releases/1.5.txt
|
|
Work done by Walter Doekes and Trac alias knoeb. Reviewed by Simon
Charette.
|
|
Of course, __nonzero__ alias has been kept for Python 2 compatibility.
|
|
version. Refs #15702 -- thanks to jonash for the patch.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@15927 bcc190cf-cafb-0310-a4f2-bffc1f526a37
|
|
Thanks, Jeremy Dunck.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@11901 bcc190cf-cafb-0310-a4f2-bffc1f526a37
|
|
combining different connector types.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@8413 bcc190cf-cafb-0310-a4f2-bffc1f526a37
|
|
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
|
|
This is a big internal change, but mostly backwards compatible with existing
code. Also adds a couple of new features.
Fixed #245, #1050, #1656, #1801, #2076, #2091, #2150, #2253, #2306, #2400, #2430, #2482, #2496, #2676, #2737, #2874, #2902, #2939, #3037, #3141, #3288, #3440, #3592, #3739, #4088, #4260, #4289, #4306, #4358, #4464, #4510, #4858, #5012, #5020, #5261, #5295, #5321, #5324, #5325, #5555, #5707, #5796, #5817, #5987, #6018, #6074, #6088, #6154, #6177, #6180, #6203, #6658
git-svn-id: http://code.djangoproject.com/svn/django/trunk@7477 bcc190cf-cafb-0310-a4f2-bffc1f526a37
|
