"All stores support key expiration, but only memcache supports it natively. All other stores
emulate expiration." Redis doesn't support volatile keys??
Also, does it allow access to a DB's tuning parameters? It makes a great difference whether to use Tokyo's B+ tree database or its hash database ...
It turns out the code used the Redis native expiration, but it wasn't compatible with Redis 2.x. So I fixed both problems. I sent a pull request. We'll see if it makes it into main.
On the plus side, I used something similar to use my caching store back when it was MemcachedDB, and switching to Redis required a one-line change in a config file rather than refactoring. (Learn from my mistake, everyone: skip MemcachedDB, go straight to Redis, collect $200.)
I use it on multiple sites (to cache http downloads, delicious tags api calls etc). You can start with a simple filesystem store (moneta/basic_file) and move to another store when needed.
Interesting looking at the network graph on this repo. Lots of forking but no merging in the months since features where added to wycats' repo. Seems the project could use a maintainer!
I've been working on a rework on a branch that should be merged in this weekend. It takes a lot of the feedback I've gotten and existing forks into consideration, as well as lessons learned from Rack.
It was originally an experiment, and I didn't notice the activity around it until recently. Stay tuned :-D
"All stores support key expiration, but only memcache supports it natively. All other stores emulate expiration." Redis doesn't support volatile keys??
Also, does it allow access to a DB's tuning parameters? It makes a great difference whether to use Tokyo's B+ tree database or its hash database ...