News for hackers. Stuff that matters.
Re:Moneta - a unified interface to key/value stores by uuid on Saturday July 10, 2010 @09:15AM (#1503584)
Interesting, and potentially useful. However:

"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 ...

Re:Moneta - a unified interface to key/value stores by subwindow on Saturday July 10, 2010 @01:44PM (#1504031)
Also, re: tuning parameters. You can use them, in some circumstances.

For tokyo in particular, it assumes tch. It'd be a 1-2 line fix to add in support for tcb or tcf. I don't know enough about Tokyo to test it, however.

Also, you can use tcb with Tyrant, which Moneta supports.

Re:Moneta - a unified interface to key/value stores by subwindow on Saturday July 10, 2010 @12:02PM (#1503845)
That was my first thought as well. The expire/expireat commands are one of the main reasons why I chose Redis.

I'm honestly not sure why wycats would make that statement. It's not like the interface for expiration is particularly opaque.

Re:Moneta - a unified interface to key/value stores by petercooper on Saturday July 10, 2010 @01:38PM (#1504020)
Because moneta is not new at all, look at the commit dates :-) It only seems to have made it to HN because someone resurfaced it on Reddit recently.

I asked wycats about this and he said he plans to do some serious reworking on it soon.

Re:Moneta - a unified interface to key/value stores by subwindow on Saturday July 10, 2010 @01:35PM (#1504015)
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.

http://github.com/subwindow/moneta

As a side note, the library is pretty simple at this point. The way the tests are set up is pretty excellent as well.

Re:Moneta - a unified interface to key/value stores by technoweenie on Saturday July 10, 2010 @12:19PM (#1503876)
I don't think Moneta's Redis interface uses the ruby expiration code: http://github.com/wycats/moneta/commit/522be344cfeddb4a4dbf8...
Re:Moneta - a unified interface to key/value stores by tptacek on Saturday July 10, 2010 @10:46AM (#1503705)
Using this with Redis (at least) misses much of the point of Redis, which has an especially rich API.
Re:Moneta - a unified interface to key/value stores by patio11 on Saturday July 10, 2010 @11:16AM (#1503757)
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.)
Re:Moneta - a unified interface to key/value stores by avar on Saturday July 10, 2010 @09:00AM (#1503570)
This is similar to the CHI and Cache modules for Perl: http://search.cpan.org/perldoc?CHI http://search.cpan.org/perldoc?Cache
Re:Moneta - a unified interface to key/value stores by thibaut_barrere on Saturday July 10, 2010 @01:59PM (#1504055)
API-cache is a convenient caching layer that works on top of Moneta:

http://github.com/mloughran/api_cache

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.

Re:Moneta - a unified interface to key/value stores by benatkin on Saturday July 10, 2010 @02:29PM (#1504106)
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!

http://github.com/wycats/moneta/network

Re:Moneta - a unified interface to key/value stores by wycats on Saturday July 10, 2010 @04:29PM (#1504286)
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