So an option to DAL.__init__(auto_cache=False, clear_cache_on_update=False) ?
auto_cache does an infinity cache time, where if there is any updates done to the db all cached selects are cleared.... and alternatively an option to only clear cached selects that have to do with the table that is selected. I feel about 50% on the idea... not sure I want every single select I make automatically cached, you definitely wouldn't want this if your competing for RAM, but if you can afford the RAM this would be nice. -Thadeus On Tue, Mar 9, 2010 at 11:00 AM, mdipierro <mdipie...@cs.depaul.edu> wrote: > You can already do > > cache.ram.clear(db._uri + '/SELECT') > > and it will clear all cached select statements. You have to specify > db._uri because you may have multiple db cached. > > Massimo > > On Mar 9, 10:37 am, Thadeus Burgess <thade...@thadeusb.com> wrote: >> What if the cache system includes a "category" or "type" field. All >> cached SQL could be of type "SQL", and then say responses can be >> cached as "RESP". This way if you refresh the cache instead of >> clearing the entire thing, we can specify >> >> cache.ram.clear(type="SQL") and it will only clear the sql typed >> entries, leaving other aspects of the cache alone. >> >> however cache.ram.clear() will still clear everything. >> >> That way, the DAL could be set a flag to clear its own cache upon >> i/u/d operations. >> >> How does this sound? If good I can start on the patch right away :) >> >> -Thadeus >> >> On Tue, Mar 9, 2010 at 10:08 AM, mdipierro <mdipie...@cs.depaul.edu> wrote: >> > You can do that if after insert/update/delete you do >> >> > db(...).select(cache=(cache.disk,0)) >> >> > Massimo >> >> > On Mar 9, 9:06 am, Praneeth <life...@gmail.com> wrote: >> >> Would it be better to have a non time based caching? Say refresh cache >> >> on DB update? >> >> Time based caching requires guessing the cache time - which in my >> >> opinion seems like a bad thing to do. >> >> >> Thoughts? >> >> >> -- >> >> Praneeth >> >> >> On 03/09/2010 08:33 PM, mdipierro wrote: >> >> >> > It is there already. >> >> >> > values=db(...).select(cache=(cache.disk,3600)) >> >> >> > 3600 is the time. >> >> >> > On Mar 9, 5:23 am, Praneeth <life...@gmail.com> wrote: >> >> >> >> Hello all, >> >> >> >> I was wondering if DAL level caching could be added. I am aware of >> >> >> cache.ram and cache.disk, but these require the usage of a decorator >> >> >> over the functions. I feel that a cache option to cache at the DAL >> >> >> level >> >> >> that could be enabled by flipping an option in db.py of an application >> >> >> would be of great help. The cache can be a key value pair of sorts, >> >> >> where the cache is flushed on each write/update and cached on the first >> >> >> read - There are probably smarter ways of doing this. >> >> >> >> Thoughts? >> >> >> >> -- >> >> >> Praneeth >> >> > -- >> > You received this message because you are subscribed to the Google Groups >> > "web2py-users" group. >> > To post to this group, send email to web...@googlegroups.com. >> > To unsubscribe from this group, send email to >> > web2py+unsubscr...@googlegroups.com. >> > For more options, visit this group >> > athttp://groups.google.com/group/web2py?hl=en. > > -- > You received this message because you are subscribed to the Google Groups > "web2py-users" group. > To post to this group, send email to web...@googlegroups.com. > To unsubscribe from this group, send email to > web2py+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/web2py?hl=en. > > -- You received this message because you are subscribed to the Google Groups "web2py-users" group. To post to this group, send email to web...@googlegroups.com. To unsubscribe from this group, send email to web2py+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/web2py?hl=en.
