I reposted and added unittest (following Tim's advice!)
On Dec 2, 11:18 pm, mdipierro <[EMAIL PROTECTED]> wrote:
> Done in trunk. now cache cleaned per app and, as you suggested, you
> can do
>
> cache.ram.clear(regex='...')
> cache.disk.clear(regex='...')
>
> Massimo
>
> On Dec 2, 8:49 pm, mdipierro <[EMAIL PROTECTED]> wrote:
>
> > 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
-~----------~----~----~----~------~----~------~--~---
