eredis only offers q() api about eredis HOT 2 CLOSED

Hi Thijs,

The reasons for not implementing this (yet) is:

• The Redis list of commands is massive, supporting all commands requires writing much wrapper code that must be maintained
• Erldis tried implementing all commands, but as Redis added more commands, it was falling behind. This led to a situation where you would have to patch it on your own and try to get your stuff merged back.
• When for example using a dict-like API, you would expect it to behave like a dict, ie. throw an exception if "fetch" fails, etc.
• In our systems we want to hide all database access inside it's own module/layer, so not having these wrappers doesn't really make that much of a difference.
• There is the issue of types: eredis:q/2 accepts an iolist, an API would have to accept types that makes sense for the API. eredis:q/2 returns {ok, DataFromRedis} if everything is ok, this is consistent across all commands and a wrapper API would have to return something that makes sense for that API call which means lots of translations and choices.
• You still need to know exactly which client you want to use, so eredis:q(MyMasterDatabase, ["SET", "foo", "bar"]), would become eredis:set(MyMasterDatabase, "foo", "bar").

With that said, I do agree that it would be a nice-to-have to offer a more high-level API. For inspiration I would suggest looking at erldis(https://github.com/cstar/erldis). In my opinion an API could offer a dict-behaviour, a list-behaviour, a sets-behaviour and a sorted-sets-behaviour.

from eredis.

Thanks for the explanation. I didn't know that the Redis api was still changing, but that would be a good reason to wait. I'll take a look at erldis later, but the pubsub feature would be more fun to add first :)

from eredis.