On May 7, 2012, at 11:05 AM, Anthony wrote: >> If you just need to store data for a single user across requests, you can >> store it in the session (each user has a separate session). But if you need >> to store data from multiple users and then process it all together, you can >> store it in the cache: http://web2py.com/books/default/chapter/29/4#cache. > > That might be just slightly unsafe, don't you think, if a piece of data gets > evicted before it's needed? I'd prefer to limit caching to data that can be > recreated when it's not found in the cache. > > An alternative might be a memory-based SQLite database, taking care not to > let it leak (a consideration regardless of the implementation). > > Doesn't a memory-based db have the same problem -- you have to purge at some > point and could therefore "evict" data before it's needed in that case as > well? > > Also, is there a way to persist a memory-based SQLite db in web2py? I thought > they would only persist for a single request. >
Maybe so; that would be a problem, wouldn't it? Be nice to have a persistent memory-based db. WRT cache persistence, it's one of those things that should normally work just fine, but I tend to be suspicious of my intuitions of this kind of thing. Nasty if it works great 99.9% of the time. My thinking re db is that you'd be able to implement an explicit purge policy, and only purge stuff you were willing to do without. Presumably that'd be necessary; there's no guarantee that every transaction would complete gracefully and in a bounded time, I suppose.
