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. -- Roché Compaan Upfront Systems http://www.upfrontsystems.co.za