Russell Keith-Magee wrote:
While I conceed that Article.objects -> set of all objects is a very
nice mental model, I can see us working ourselves into knots trying to
overcoming caching problems on an Article.objects 'manager QuerySet'.
all() isn't quite as nice as a mental model, but it certainly doesn't
offend me, and it seems to have a lot less problems (or at least is
restricted to problems inherent in any caching mechanism).
You seem to have just repeated what I said .. I'm trying to work out
what point you are making.
My position is :
The name '.all()' in no way indicative of what the purpose of the call
is. It is an accidental name chanced upon during implementation as far
as I can see.
I explained a way that would allow us not to have to use
'.all()'/'.cached()' ( storing the caches in a global dict keyed by a
tuple of (db_context,queryspec) rather than in the queryset itself).
This is clearly doable.
When I said 'the only real trouble situation', I was explaining why this
was needed at all, not saying 'this doesn't really matter'.
So basically the choices are:
a) .all(), I think it is fairly confusing in mapping the name to the
semantics
b) .cached(), the same semantics but at least it does what it says..
c) externalise the caching, but this means decisions have to be made
about how to set the db_context etc etc. Logically this should be done
via events or middleware... and if transactions/unitofwork gets looked
at that would be the logical db_context I'm talking about above...
but I'm sure there will be cries of 'coupling' whatever decision is made
here... sigh.
