librelist archives

« back to archive

Resque Plugin API for Redis Access

Resque Plugin API for Redis Access

From:
Grant Austin
Date:
2013-06-28 @ 18:04
could not decode message

Re: [resque] Resque Plugin API for Redis Access

From:
Eoin Coffey
Date:
2013-06-28 @ 18:16
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 <gaustin@gmail.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.
>
> Thanks,
> Grant
>
>

Re: [resque] Resque Plugin API for Redis Access

From:
Eoin Coffey
Date:
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:


https://github.com/ecoffey/redis-breadcrumbs/blob/master/test/functional/as_test.rb


On Fri, Jun 28, 2013 at 12:16 PM, Eoin Coffey <ecoffey@gmail.com> 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 <gaustin@gmail.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.
>>
>> Thanks,
>> Grant
>>
>>
>