Fixed #10181 -- Handle an EmptyResultSet exception case properly in nested querysets.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@9951 bcc190cf-cafb-0310-a4f2-bffc1f526a37
This commit is contained in:
parent
a605a8fe08
commit
851461aa72
|
@ -50,7 +50,7 @@ class WhereNode(tree.Node):
|
|||
if hasattr(obj, "process"):
|
||||
try:
|
||||
obj, params = obj.process(lookup_type, value)
|
||||
except EmptyShortCircuit:
|
||||
except (EmptyShortCircuit, EmptyResultSet):
|
||||
# There are situations where we want to short-circuit any
|
||||
# comparisons and make sure that nothing is returned. One
|
||||
# example is when checking for a NULL pk value, or the
|
||||
|
|
|
@ -1048,11 +1048,14 @@ performance problems on backends like MySQL.
|
|||
[<Annotation: a1>]
|
||||
|
||||
Nested queries should not evaluate the inner query as part of constructing the
|
||||
SQL. This test verifies this: if the inner query is evaluated, the outer "in"
|
||||
lookup will raise an EmptyResultSet exception (as the inner query returns
|
||||
nothing).
|
||||
>>> print Annotation.objects.filter(notes__in=Note.objects.filter(note="xyzzy")).query
|
||||
SELECT ...
|
||||
SQL (so we should see a nested query here, indicated by two "SELECT" calls).
|
||||
>>> Annotation.objects.filter(notes__in=Note.objects.filter(note="xyzzy")).query.as_sql()[0].count('SELECT')
|
||||
2
|
||||
|
||||
Bug #10181 -- Avoid raising an EmptyResultSet if an inner query is provably
|
||||
empty (and hence, not executed).
|
||||
>>> Tag.objects.filter(id__in=Tag.objects.filter(id__in=[]))
|
||||
[]
|
||||
|
||||
Bug #9997 -- If a ValuesList or Values queryset is passed as an inner query, we
|
||||
make sure it's only requesting a single value and use that as the thing to
|
||||
|
|
Loading…
Reference in New Issue