[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
- Subject: Re: Error handling strategy for Redis multi-bulk replies, in context of Lua bindings
- From: Alexander Gladysh <agladysh@...>
- Date: Thu, 24 Mar 2011 20:14:17 +0300
On Thu, Mar 24, 2011 at 19:57, Jerome Vuarand <jerome.vuarand@gmail.com> wrote:
> 2011/3/24 Alexander Gladysh <agladysh@gmail.com>:
>>>> I would wrap status/error replies in a status userdata object with a is_error
>>>> field/method. For string/number reply values convert them to basic lua
>>>> string/numbers.
>>> Interesting idea. I'm trying to imagine how the user's code would look
>>> like. Wouldn't it be too cumbersome to work with?
>> Also, I'm concerned by the overhead — status replies are common in the
>> protocol, and creating an userdata per each can be too much (strings
>> should be cheaper, and, besides, users do not need to look into status
>> codes that often, I think).
> To avoid clash with strings, you can have your status codes be
> userdata without allocating one at each request. Just keep a redis.ok
> value that you return, and client code can write "if status==redis.ok
> then end".
Have to do strcmpi() or something for this in C code first. (Not a big problem.)
> That being said, I think (please correct me if I'm wrong) that string
> allocation is not cheaper in terms of execution speed than userdata
> allocation, unless most of the strings are expected to be already
> interned (which completely depends on the data your client will put in
> your redis db).
Well, as I understand, in this case, it does not depend on data in db
— we're discussing status codes.
There are (I think, please correct me) two common status replies
(REDIS_REPLY_STATUS) in Redis: OK and QUEUED (for multi/exec).
I could cache these two, and if I encounter anything else, I'll just
allocate a new one. (Actually, I'll cache a Redis NIL as well — looks
like it needs to be separate from Lua nil — not so sure about this
though.)
But the question is how to actually write the thing then:
1. Where is the best place to store actual hiredis.OK and
hiredis.QUEUED values, so they are easily accessible by the C code?
2. What is the best way to handle REDIS_REPLY_STATUS case? Just bite
the bullet and do two string comparisons? Or does anyone see something
more clever?
Thanks,
Alexander.
- References:
- Error handling strategy for Redis multi-bulk replies, in context of Lua bindings, Alexander Gladysh
- Re: Error handling strategy for Redis multi-bulk replies, in context of Lua bindings, Robert G. Jakabosky
- Re: Error handling strategy for Redis multi-bulk replies, in context of Lua bindings, Alexander Gladysh
- Re: Error handling strategy for Redis multi-bulk replies, in context of Lua bindings, Alexander Gladysh
- Re: Error handling strategy for Redis multi-bulk replies, in context of Lua bindings, Jerome Vuarand