I cannot think of a better way but, if you use cache.ram, you can find the actual cached data in
cache.ram.meta_storage[request.application] which is a python dict. It if not thread safe to write in there unless you do: cache.ram.locker.lock() cache.ram.meta_storage[request.application][key]=value cache.ram.locker.release() You can try find out what is in there and clear it yourself. On Feb 26, 7:59 am, Carl <[email protected]> wrote: > a thought... > > would anyone recommend that one avoids passing a cache parameter > into .select() and instead handle the cache keys oneself? > that would enable smarter clearing of cache keys when the database is > updated and so rely on less internal Web2py detail > > On Feb 25, 5:18 pm, Carl <[email protected]> wrote: > > > > > > > > > Web2py has an elegant interface to using cache (ram/disk/memcache) but > > is there a hole when it is applied to database actions? > > > When using database .select() statements one can specify the use of > > caching using... > > e.g., ... .select(cache=(cache.ram, 60 * 60 * 24)) # cache result for > > a day > > > To flush a cache I can't find a clean/targeted solution. > > > I've read postings (mdipierro, 9mar2010): > > ... after insert/update/delete you do > > db(...).select(cache=(cache.disk,0)) > > > or: > > cache.ram.clear(db._uri + '/SELECT') > > > The former flushes all the contents of the cache and the latter, using > > the private variable _uri, restricts the flush to all database > > selects. > > > Is there a better way extend Web2py's cache system to supporting > > databases? > > > Can we get one more step of specificity? Namely, can we limit the > > flush to a specific table or tables?
