Let me think about this for version 1.53.... we could make one cache.ram[storage] for each app. cache.ram contains the request anyway and it knows the request.folder...
Massimo On Dec 2, 6:33 pm, achipa <[EMAIL PROTECTED]> wrote: > Of course by default it would be a default=None param, so not much > overhead there. Clearing the cache for all apps doesn't always cut it > as it's pretty certain not much time will pass till you encounter an > update/delete on busy sites, which would cause to throw the whole > cache out right when you need it the most. What do you think about the > last-modified attribute for tables I mentioned above ? If it's newer > than the cache timestamp, we rewrite the cache. Minimum overhead, no > user interaction required, maximum cache efficiency ? > > On Dec 2, 11:31 pm, mdipierro <[EMAIL PROTECTED]> wrote: > > > I just posted 1.52 which allows for > > > cache.ram.clear() > > > and it clear all cache for all apps. > > What you ask would require looping and it may be slow. > > > Massimo > > > On Dec 2, 4:21 pm, achipa <[EMAIL PROTECTED]> wrote: > > > > Hey ! You just put that in ! :) Would a cache.ram.clear(regex=r'') be > > > too much to ask for ? > > > > On Dec 2, 11:03 pm, mdipierro <[EMAIL PROTECTED]> wrote: > > > > > oh... cache.ram.storage.clear() > > > > > On Dec 2, 3:58 pm, achipa <[EMAIL PROTECTED]> wrote: > > > > > > Nice trick ! Although this seems usable only in the vicinity of the > > > > > original select query, it becomes unwieldy if all the selects have to > > > > > be gone through manually... Maybe some sort of cache.invalidate > > > > > (cache.ram, db.table) would help ? Or better yet, a last-modified > > > > > attribute for the table so the select would automatically know if the > > > > > cache is out of sync (not perfect as it cannot know if you modified > > > > > the table outside of the stock web2py methods, but hey, still way > > > > > better than nothing) ? > > > > > > On Dec 2, 7:32 pm, mdipierro <[EMAIL PROTECTED]> wrote: > > > > > > > If you are using cache.ram > > > > > > > cache.ram(db._uri+'/'+db(....)._select(....),None,0) > > > > > > > Will invalidate the result of db(....).select(....) without > > > > > > executing > > > > > > the select. > > > > > > > notice the _select(...) instead of select(...). Does not work on > > > > > > GAE. > > > > > > > Massimo > > > > > > > On Dec 2, 12:15 pm, achipa <[EMAIL PROTECTED]> wrote: > > > > > > > > Is it possible to invalidate a select cache ? For example if I > > > > > > > know > > > > > > > that I'm about to update a table I would like to invalidate the > > > > > > > cache > > > > > > > that pertains to that table so that other controller functions can > > > > > > > update the cache and not work with stale data. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "web2py Web Framework" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/web2py?hl=en -~----------~----~----~----~------~----~------~--~---
