I actually started building ROC before redis-objects was released. But I stuck with using and developing ROC for a couple of reasons:
1. TransientStore is really useful for testing and for re-using redis code in scenarios that don't require persistence
2. As well as implementing the Redis commands, the ROC objects also perfectly mimic the APIs of their Ruby-core equivalents (except for a few destructive methods that are not possible to mimic).
In addition, there's now a third reason:
3. I recently added eval/lua support, which I don't think redis-objects has yet.
Comments
https://github.com/nateware/redis-objects is clean, mature, and has worked very well for us in several production systems. What makes ROC better?
I actually started building ROC before redis-objects was released. But I stuck with using and developing ROC for a couple of reasons:
1. TransientStore is really useful for testing and for re-using redis code in scenarios that don't require persistence
2. As well as implementing the Redis commands, the ROC objects also perfectly mimic the APIs of their Ruby-core equivalents (except for a few destructive methods that are not possible to mimic).
In addition, there's now a third reason:
3. I recently added eval/lua support, which I don't think redis-objects has yet.
That's my question too.
ROC's TransientStore thing might be a win for testing.