Re: [resque] Resque Plugin API for Redis Access
- Eoin Coffey
- 2013-06-28 @ 18:25
I guess I didn't have this in the readme, but here is how I would expose
the fixed set of Resque specific keys to other pieces:
On Fri, Jun 28, 2013 at 12:16 PM, Eoin Coffey <firstname.lastname@example.org> wrote:
> This is a gem I've fleshed out for describing domain use cases against
> redis, and may be useful for resque (indeed all my examples are for a
> resque worker ;-)) https://github.com/ecoffey/redis-breadcrumbs
> On Fri, Jun 28, 2013 at 12:04 PM, Grant Austin <email@example.com> wrote:
>> Hi all,
>> Resque plugins need an API that allows them to manipulate Redis without
>> directly accessing the internal Redis instance. Here is a little
>> in-progress proposal I'd like to get some feedback on.
>> There are two decent broad approaches to the API that I've come up with:
>> 1. A "class per Redis data-type" implementation.
>> a. I would consider naming some data types more descriptively, such as
>> OrderedSet instead of ZSet.
>> 2. A "makes a lot of inferences" query implementation.
>> There's one obvious solution that I don't like, but will mention anyway.
>> It would be pretty straightforward to just provide a class (maybe
>> Resque::Redis::API that forwards all of the Redis commands to the
>> underlying Redis instance). I'm not sure why I don't like it, other than it
>> seems a little too simple, and I like overcomplicating things. :-)
>> Below are some examples taken from resque-scheduler of what I'm thinking
>> (gist: https://gist.github.com/gaustin/5886588). They are incomplete but
>> I hope it gives enough information for folks to suggest which direction
>> they see as having the most merit. There's no implementation to back these
>> up yet, as I'm curious to hear others thoughts before I take a stab at it.
>> A couple of questions came up while composing these examples. First, is
>> it a good idea to simplify some commands like LREM so that you don't have
>> to remember the magic values. Second, is it a good idea to normalize method
>> names across data types (e.g., SCARD, LLEN and HLEN could all be `size`).
>> Third, should the API require values passed in to be encoded and should the
>> API return decoded values.
>> Regarding the third question, I might say that encoding/decoding is a
>> responsibility outside of the API and that it shouldn't care about the
>> values, just set and return whatever you give it. However, I don't really
>> have strong feelings about it.
>> Any input would be greatly appreciated.