Forum OpenACS Improvement Proposals (TIPs): Re: TIP #57 (Proposed) Add caching db_* API (based on Greenpeace/Berkeley work) to 5.2

Collapse
17: Re: TIP #57 (Proposed) Add caching db_* API (based on Greenpeace/Berkeley work) to 5.2 (response to 1)
Posted by Don Baccus on 04/10/04 12:01 AM
Tilman, the problem is that you might want to use something other than an object_id as a key.

Jeff ... the permissions case is not easily solvable and naive use of the db_* caching API will work exactly as the current util_memoize approach to caching forums or other content.  In other words properly written queries (that do an EXISTS query against the permissions view) won't honor a perm change until your cache is flushed.

This isn't good ... but then again it's true today with util_memoized procs containing the equivalent queries.  This extension to the db_* API won't solve such problems, it will just simplify caching.  Coherent permissions caching is a problem unto itself which needs a special solution regardless of whether caching is implemented via a proc cache method like util_memoize or a smart db_* caching API.

A simple solution would be to have the permissions Tcl API flush all cache pools registered to the db_* API.  While this is gross overkill you'd still get the advantages of caching most of the time since ... callbacks are another approach?  Not sure ... it's not a simple problem.

Collapse
18: Re: TIP #57 (Proposed) Add caching db_* API (based on Greenpeace/Berkeley work) to 5.2 (response to 17)
Posted by Tilmann Singer on 04/12/04 05:25 PM
Ok, not keying always to object_ids makes sense - I still don't get what is meant by composite keys though. Just a list of arbitrary strings where each string is a freely choosable key? Anyway,

Approve.

And yes, when permission checks are involved caching should be avoided of course. Flushing in the tcl api permission call won't catch all cases either, there are lots of calls to the pl/sql permission api in the toolkit.