On 11/07/2006, at 12:22 PM, Malcolm Tredinnick wrote:
>
> Tricky implementation ("tricky" != "bad"), but it looks like it should
> work more or less. Don't you need to override every public method of
> QuerySet, not just get() (e.g. filter(), order_by()...)?
hmm.
we could use self._get_sql_clause() instead of model.
for the Real Cache one I plan on implementing some kind of version
number which gets updated everytime
the 'save()' function gets called on the model.
so in this case the key would now be:
SQL-clause:version#:args
or possibly the md5 of that (with a sanity check on the result)
I'll try to get it coded tomorrow.
>
> In a long running process, memory usage is going to be an issue.
> You are
> essentially caching the results of every single query during the
> runtime
> of the process, aren't you? So if I retrieve something that
> temporarily
> sucks in a couple of thousand lines of data and I only need it once, I
> pay the memory penalty forever. A "sorted dict" structure that allows
> you to remove the oldest entries easily would work around this
> somewhat
> (managing total memory usage wouldn't be easy, but you could manage
> the
> number of cached querysets). I'm a little concerned about whether an
> "active" application is just going to end up thrashing the cache a lot
> without seeing any real benefit, but the overhead of that should
> not be
> too much. And it's testable once we have an implementation anyway.
>
> I think your idea is probably worthwhile.
>
> Regards,
> Malcolm
>
>
> >
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
