On Fri, 2007-02-23 at 20:43 +0100, Dieter Maurer wrote:
> Roché Compaan wrote at 2007-2-23 18:44 +0200:
> > ...
> >Cool idea. I haven't done any coding involving OFS.Cache though. Looking
> >at it briefly it looks like one can modify the catalog to subclass
> >OFS.Cacheable and then use the ZCacheable_get, ZCacheable_set and
> >ZCacheable_invalidate methods to interact with a cache manager. This
> >needs to be pretty explicit though. Are there any side effects that I
> >should guard against if the catalog subclasses OFS.Cache?
> A RAMCache cannot cache the result afte "LazyMap" has been applied
> to it. The result before "LazyMap" can be cached and the cached
> value needs to be "LazyMap"ped before it is returned.
Thanks for that pointer. It's good that way, it should make invalidation
easier. It could be as simple as invalidating any cached result that
contains the documentId being indexed. Do you see any problem with the
following invalidation strategy:
If the 'documentId' exists (cataloging existing object), invalidate all
cached result sets that contain the documentId.
If the 'documentId' doesn't exist (cataloging new object), invalidate
all result sets where the ids of indexes applied, are contained in the
cache key for that result set.
Upfront Systems http://www.upfrontsystems.co.za
Zope-Dev maillist - Zope-Dev@zope.org
** No cross posts or HTML encoding! **
(Related lists -