Ohm kind of bugs me. Redis is very different from other databases. I don't think it's a good idea to hide the raw Redis API from your application, for a couple reasons:

* It's important to understand the keys your application is using (and my experience with Ohm was that, in particular with indexing, we wound up with an explosion of keys).

* The raw Redis API offers lots of opportunities to restructure your application; two good examples are set operations and blocking operations.

Redis is quirky in the best possible way. You should get very familiar with it before you opt to abstract it away.

While I agree that Redis (and other nosql databases) are very different than relational ones, I think that the classic model oriented approach makes getting the simple stuff out of the way very easy.

"Makes easy things easy, and hard things possible". Redis makes the hard things possible, Ohm focuses on the easy things made easy part. I do agree of course that understanding your tools is of vital importance.

Agreed 100%, that's why my favorite redis abstraction is http://github.com/nateware/redis-objects, maps the awesomeness of redis in clean and atomic way.

redis-object is useful but it's not closer to Redis. In terms of functionality, it is comparable to Nest (http://github.com/soveran/nest), but because it translates Redis commands to Ruby syntax, it has 1026 lines of code vs Nest's 32. Ohm, which in your view is not close to Redis and more complex, is actually closer because it uses Nest to solve that problem (and it's just 764 lines of code, 262 less than redis-objects).

Ohm shouldn't be used for everything, but for the specific design pattern of mapping objects to Redis, it helps you to avoid coding errors.