t into a wsgi
middleware, there is no view, so what to do with it?
- my answer right now is go ahead and call it, passing it the
wrapped wsgi app.
i'd love comments or suggestions.
travis
On Mar 31, 1:29 pm, Travis Parker wrote:
> On Tue, Mar 31, 2009 at 1:12 PM, Waylan Limberg wrote:
On Tue, Mar 31, 2009 at 1:12 PM, Waylan Limberg wrote:
>
> On Tue, Mar 31, 2009 at 2:21 PM, Travis Parker
> wrote:
> >
> [snip]
> >
> > 2. settings (views -> apps, dj middleware -> wsgi middleware)
> > i don't have nearly as nice a proposal for d
On Mar 31, 12:04 pm, Alex Gaynor wrote:
> On Tue, Mar 31, 2009 at 2:21 PM, Travis Parker wrote:
>
>
>
>
>
> > hello django devs,
>
> > It was nice to meet a few of you at pycon. I talked briefly with jacob
> > about a plan to improve django's ability t
n our error pages sure are nice. maybe
this is an argument for pulling the error pages into exception
middleware which could then be converted to wsgi middleware.
travis parker
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Googl
> I'd be very surprised if .filter or .order_by would do completely
> different things based on whether a queryset is already filled or not.
> Currently queryset constructing methods are not completely opaque
> abstractions of "filtering" and "ordering", and it's good. I think
> simplicity here wi
('field')# these two should
Model.objects.order_by('field') # always be the same
So the parallel implementation problem comes out here. But at least
filter(), exclude(), and values() can be done without requiring new
database traffic.
On Apr 15, 7:33 pm, Travis Park
> Because every time you modify a QuerySet you are changing the results
> that will be returned. Calling filter() will restrict the results.
> Calling order_by() will change the order the results are returned in.
> And so on. Thus, the cache of the queyrset that was cloned is invalid
> for the new
Is there a reason that QuerySet methods like order_by() or filter()
don't simply pass on an appropriately modified version of their own
cache to the new QuerySet?
I was just recently optimizing database usage in a django app and
found myself managing these things myself (sorted(qs) instead of
qs.
