On Apr 9, 2012, at 12:57 PM, Wichert Akkerman wrote:
>
> Would you also be willing to accept a pull request (assuming you use git,
> otherwise a patch?) that adds a redis backend to dogpile directly?
sure
>
>> It seems like we'd almost be better off taking the "stats" logic wired into
>> "load" and just making that an optional feature of dogpile, so that all the
>> backends could get at hit/miss stats equally. The get/set/lock things i see
>> in retools would only give us like a dozen lines of code that can actually
>> be reused, and putting keys into redis and locking are obviously almost the
>> same as a memcached backend in any case. It's just a question of, which
>> project wants to maintain the redis backend.
>
> The statistics are certainly very useful.
>
>> He appears to have a "region invalidate" feature taking advantage of being
>> able to query across a range in redis, that's not something we can
>> generalize across backends so I try not to rely on things like that, but
>> dogpile can expose this feature via the backend directly.
>
> Region invalidate is very very useful in my experience: for us it allows us
> to have a management-system invalidate caches for a running website without
> having to make it aware of all the implementation details of the site. We can
> now simple say 'invalidate everything related to magazines' instead of
> invalidating 15 different functions separately (which will get out of sync as
> well).
great, just not something that's possible with memcached, for example.
>
>> The function decorators and the dogpile integration in retools are of course
>> derived from Beaker the same way dogpile's are and work similarly.
>> Dogpile's schemes are generalized and pluggable.
>
> A problem I have with the Beaker and retools decorators is that they make it
> very hard to include context from a view into a cache key. For example for
> complex views it is very common that you want to cache a helper method for
> the view class, but you want the context and things like
> request.application_url to be part of the cache key, but those are never
> passed to the method. That leads to code like this:
>
> class MyView:
> @some_cache_decorator
> def _slow_task(self, context_id):
> # Do something
>
> def slow_task(self):
> return self._slow_task(self.context.id)
>
> one approach I used to take was to use a decorator which could take a
> function parameter which returned extra cache keys. You could use that like
> this:
>
> class MyView:
> def _cachekey(self, *a, **kw):
> return (self.request.application_url, self.context.id)
>
> @some_cache_decorator(extra_keys=_cachekey)
> def slow_task(self):
> # Do things here
Well I've got the function that comes up with the cache key as pluggable. So
you can make your own that interprets the "namespace" parameter as a tuple or
other, if not a plain string as its usual function, then snatches whatever
you'd like from each function call.
>
>
>> It seems like Ben stuck with the @decorate("short-term", "namespace") model
>> we first did in Beaker, whereas with dogpile.cache though the API looks more
>> like flask-cache (http://packages.python.org/Flask-Cache/), where you have a
>> "cache" object that provides the decorator.
>
> That sounds like the dogpile approach does not supported environments where
> you have multiple copies of the same application in the same process space
> but using different configurations? That's a rare situation, but to some
> people appears to be to important.
assuming you're talking about beaker's middleware, all it did was stick a
CacheManager object in the wsgi environ. You can certainly do that with
dogpile cache regions too.
After considering some approaches I think you could just subclass CacheRegion
and overrride "backend" and "configure" to pull from the wsgi environment, some
system of making it available would need to be devised (pylons made this easy
with the thread local registries but I understand we don't do that with
Pyramid....)
--
You received this message because you are subscribed to the Google Groups
"pylons-discuss" 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/pylons-discuss?hl=en.
