I don't actually know, but I have a guess... Ordinarily the blah.objects.exclude(...).filter(...) doesn't actually perform the query. It instead happens when you use it in, for example for obj in qset. But your fancy debugger may be trying to get variable values to display in a variables value panel. Single stepping in, rather than over, in the example above, will normally step through the exclude, then step through the filter, where at least self is already a queryset object, but which doesn't have the filter applied. filter's job is to make a new queryset with updated sql. But in trying to have something to show for self, the debugger probably effectively calls __str__(), which causes the queryset (the original, without filter applied) to be evaluated.
You might try stepping through this in pdb directly, and not looking at the variables, to see if it then works correctly. Still, unless you're trying to teach yourself how django works, I'd try to avoid stepping through the interior. Bill On Thu, Nov 19, 2009 at 5:28 PM, Nick Arnett <nick.arn...@gmail.com> wrote: > I'm not sure if this is a bug... couldn't find anything quite like it in the > tracker. I'm using Komodo as my IDE. When I step through source, the > filters in a Model.objects.filter method are ignored. Instead of getting > the handful of rows that I want from my database, Django (1.1) grabs the > entire table -- there's no WHERE clause in the SQL it executes (this is with > MySQL). When I run it outside the debugger, or avoid stepping into the > "magic" parts of the database stuff, it behaves properly - the WHERE clause > is present. > > For an awful moment, I thought it was trying to cache the entire table... > > This makes debugging with Komodo somewhat challenging, since the table where > I first encountered this has 50,000 rows that include the full text of web > pages. Lots of data and even with plenty of memory, my machine starts > thrashing horribly when this happens. > > Anybody aware of this as a known issue? Any fix? > > Since I can avoid it by not stepping through the "magic" parts of the > database stuff, it isn't critical. > > Nick > > > -- > > You received this message because you are subscribed to the Google Groups > "Django users" group. > To post to this group, send email to django-us...@googlegroups.com. > To unsubscribe from this group, send email to > django-users+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/django-users?hl=. > -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-us...@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=.
