Hi Łukasz,
On Apr 4, 8:43 pm, Łukasz Rekucki <[email protected]> wrote:
> It's best to report bugs on the tracker. Otherwise, they'll die in
> infinite depths of everyone's mailboxes.
that sounds like too much hassle for me. Please, feel free to report
this. Here's the "safe" patch:
diff -rupN django/db/models/sql/where.py django.fix//db/models/sql/
where.py
--- django/db/models/sql/where.py 2011-04-06 19:48:07.000000000
+0200
+++ django.fix//db/models/sql/where.py 2011-04-06 22:05:32.000000000
+0200
@@ -102,6 +102,7 @@ class WhereNode(tree.Node):
empty = False
continue
except FullResultSet:
+ empty = False
if self.connector == OR:
if self.negated:
empty = True
> It's still not very clear to me what problem are you describing.
If you have a WhereNode instance with a single EverythingNode instance
as a child, then calling `as_sql` method on that WhereNode instance
results with EmptyResultSet exception, which is bad. That's because in
such case, in the body of the `WhereNode.as_sql` method a variable
called `empty` will never get set to False value, although it looks
like it definitely should.
> If
> you could produce a queryset that generates wrong SQL, it would
> clearify things.
>
> >> How one can get (AND: (EverythingNode))WhereNodeto be
> >> generated?http://code.djangoproject.com/browser/django/trunk/django/db/models/s...
>
> Good question. You can see it's generated in combine()[1], but I'm not
> sure how you can make a Query object with "self.where" attribute that
> would evaluate to False.
Just don't add any filters to QuerySet instance, e.g.
bool(User.objects.all().query.where)
A QuerySet instance to reproduce this bug is a "too much hassle"
thing. It's not easy for me to generate QuerySet containing query with
WhereNode with singleton EverythinNode child. (E.g.
User.objects.filter(username__isnull=False) & User.objects.all() does
not do the trick.) I've managed to capture that in a running system
with big query on the lhs of the & operator and mptt tree managers
query set on the rhs. A self-contained description based on that would
require disproportional amount of work from my side in comparison to
just comprehending the bug's essence + assurance that this case is
actually reachable (which, is not important at all even if it
shouldn't be reachable - the bug is still in the `as_sql` method). I
guess some swift Django ORM developer could have produce such test
case much more effectively, thus only mail from my side. Imvho, a safe
fix is clear and instant (cf. removing `continue` to reach
`empty=False` later on).
Best regards,
Mikołaj
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
