On Saturday 18 March 2006 00:50, Russell Keith-Magee wrote:
> Again, look back at the archives.
>
> http://groups.google.com/group/django-developers/browse_thread/thread
>/4a6c67a2df095b43/bb00c30c7ba63bdf
>
> For the record, I would be +1 on Article.objects returning a
> non-cached query set, an
On 3/17/06, Luke Plant <[EMAIL PROTECTED]> wrote:
> >>> len(connection.queries)
> 3
This is by design. Every call to all() produces a new query set. This
behaviour has been discussed a few times, usually in the context of
renaming all() 'cached()', whether caching should be the default or an
opti
Max Battcher wrote:
> So, I'm not sure if such an improvement is really necessary, again as
> the biggest case I see _for_ it being template performance, and I'm
> wondering if there might be a better way to optimize that single edge
> instead (ie, is it worth it to have some caching added to
> d
Correct me if I'm wrong (I don't currently have a system to test this
with), but you can already do this caching yourself (if you need it)
by:
>>> c = Camp.objects.all()[1]
>>> myleaders = c.leaders.all()
Further iterations of myleaders should use the cached queryset.
Obviously, this doesn't he
Hi all,
The current descriptor implementation is inefficient for related object
lookups. For example, using my 'Camp' model, which has a many-to-many
'leaders' relationship:
>>> c = Camp.objects.all()[1]
>>> len(connection.queries)
1
>>> c.leaders.all()
[Jason & Ruth Phillips]
>>> len(connect
