[Zope-PAS] PAS Caching

[Chris McDonough]

On Mon, 2004-11-08 at 07:58 +0100, Jens Vagelpohl wrote:
> On Nov 8, 2004, at 3:22, Chris McDonough wrote:
> 
> > Jens,
> >
> > I've looked at this code and I'm not sure I understand why a special
> > "PASRAMCacheManager" type needs to be created and why the 
> > "PASCacheable"
> > class need to be used to implement caching on plugins.  Could we fix
> > whatever is broken about RAMCacheManager instead and use the instruct
> > authors to use the Cacheable class instead of PASCacheable?  Is there a
> > "frameworky" purpose to specializing these?
> 
> I'm subclassing RAMCacheManager to insert a different Statistics view 
> and to add a convenience method for invalidating something right from 
> that form. There wasn't anything that needed "fixing" per se on 
> RAMCacheManager, just changing to adjust to the really different needs 
> that exist in this case. As it turns out, the RAMCache model of wanting 
> to cache "views" of objects that it wants to be able to traverse to is 
> kind of an odd matchup here :/

It's handy to be able to invalidate the cache on a per-entry basis
especially for this purpose.  Actually, I'd like to be able to
invalidate it on a per-view basis, but per-entry is a good start.

Maybe we could change the implementation of RCM's ZCache_invalidate to
accept a path too?  There's no reason to need to traverse to the object
and call its ZCacheable_invalidate, we already know the path of the
thing we want to invalidate.  The path is the key into the cache entries
dict so we can still get the cache entry object, and even if the object
has disappeared (or wasn't ever there, sometimes it's desirable to cache
things that aren't persistent objects) we should still be able to
invalidate any cache entry.

If the only reason for PRCM is per-entry invalidation, I'd really like
to see that feature added to RCM proper (and see PCRM ditched).  Are
there other reasons?

Also, caching the user object proper in _findUser is probably an
accident waiting to happen.  The PAS API doesn't specify that the user
object can't be persistent (it's not in the default implementation, but
a plugin can do whatever it wants), and caching a persistent object in a
module-level global is bad news.  If we put this code in there, we need
to make it clear that the contract of createUser in IUserFactory is
required to return non-acquisition-wrapped, non-persistent objects.

- C