Redis status and integer responses

[Mike]

I'm writing a java client for Redis and am a little confused about the
choice to support both a status response type and an integer response
type. The functionality seems to overlap quite a bit between these
two. Was looking for some feedback on if/why the status response is
needed.

Why not just say that all commands can return a -ERR line if a server
error occurs, or build a little more structure into the ERR response?
For example, you could have the following spec for ERR lines:

-<2 digiit status code> <optional error string>

where status code = 01 for key not found, 02 for key returns value of
wrong type, etc ... and 99 returns sever server error (what -ERR is
used for today)

The value of this is that integer responses could just always be one
of two forms:
- Binary: where the response will always be 1 or 0
- Value: where the acceptable range can be specified by the command
documentation (e.g. positive numbers only, all real numbers, etc).

This seems like a much cleaner way to handle errors, rather than
sending some back as negative integer values. And it would certainly
make for a cleaner client library.

Thoughts?

[Salvatore Sanfilippo]

Hello, this protocol is deprecated Mike,
please try to refer to the documentation inside Git.

Also there are other Java clients that are already working!

I absolutely need to do a release with all the new things in theory,
but I'm trying to support better compression via Smaz and better
stability...

Cheers,
Salvatore

--
Salvatore 'antirez' Sanfilippo
http://invece.org

[Mike]

Okay, I'll checkout the code and take a look. Didn't realize this was
changing.

- Mike

[Salvatore Sanfilippo]

On Tue, Apr 7, 2009 at 10:30 PM, Mike <msem...@gmail.com> wrote:
>
> Okay, I'll checkout the code and take a look. Didn't realize this was
> changing.

My fault... now I put it in bold on the home page this issue :)

Cheers,
Salvatore

[Mike]

I may be dense, but I cloned the git repository and the documentation
looks the same to me. Still have the -ERR response and also negative
integer replies, for some commands, to indicate errors.

Is this the right repository: http://github.com/antirez/redis/tree/master

BTW, I know someone else is working on a java library. Hopefully I'll
be able to contribute to that. But I need something now to do some
prototyping and I enjoy the coding as an exercise anyhow ;-)

- Mike

On Apr 7, 4:33 pm, Salvatore Sanfilippo <anti...@gmail.com> wrote:

[Salvatore Sanfilippo]

On Tue, Apr 7, 2009 at 10:46 PM, Mike <msem...@gmail.com> wrote:
>
> I may be dense, but I cloned the git repository and the documentation
> looks the same to me. Still have the -ERR response and also negative
> integer replies, for some commands, to indicate errors.

Hello!

please check the html/ProtocolSpecification.html file
this and the implementation itself are the only things in sync in this moment.

[Joubin Houshyar]

On Apr 7, 4:53 pm, Salvatore Sanfilippo <anti...@gmail.com> wrote:

> On Tue, Apr 7, 2009 at 10:46 PM, Mike <msemin...@gmail.com> wrote:
>
> > I may be dense, but I cloned the git repository and the documentation
> > looks the same to me. Still have the -ERR response and also negative
> > integer replies, for some commands, to indicate errors.
>
> Hello!
>
> please check the html/ProtocolSpecification.html file
> this and the implementation itself are the only things in sync in this moment.

Hi Salvatore,

I'd appreciate your review of the following pattern for return values
as I would like to finalize the java interface for release:

Errors:

Any response from Redis beginning with a '-' will be treated as an
error and will cause an exception in the java client. Exception will
have, as its message any bytes from 1. (ex: "ERR no such key")

ALL methods throw exception (and this may change to an unchecked
exception once there is sufficient feedback), even methods that can't
normally fail, such as "ping", since:

ping
-ERR operation not permitted


This does *not* mean that value responses, such as Bulk or MultiBulk
that return responses with a '-' in offset 1 will be treated as
errors. These will return 'null'.

Return values:

1 - Status Code replies:

Commands returning Status Code will have return type of 'void'.
Error conditions, if any, are treated per the uniform error handling
above, by the throwing of an exception.

ex:
void ping () throws RedisException;


2 - Integer value replies:

a) Commands returning integer values with number semantics will have
return types of either int (or long where appropriate).

typical examples:
int llen (String key) throws ...
int lrem (String key, byte[] value, int count) throws ..

// we use long here since that is what unix epoch is represented by in
JVM
//
long lastsave () throws ...

b) Commands returning integer values with logical conditional
semantics will have return types of boolean.

// :0 -> false, :1 -> true
boolean void expire (String key, int ttl) throws ...


3 - Bulk and MultiBulk replies:

These methods will return null values for $-1 and *-1, respectively a
null byte[], and a null List<byte[]>.

$0, maps to a non-null string of length 0
*0, maps to a non-null List<byte[]> of size 0 (i.e. empty)

A List<byte[]> multibulk value can contain null members. For ex:
mget nosuchkey foo
*2
$-1
$3
bar

which maps to a List<byte[]> with list.get(0) returning null, list.get
(1) returning the byte[] for "bar".

----

Thanks in advance for reviewing this.

/Regards

[Salvatore Sanfilippo]

On Wed, Apr 8, 2009 at 2:37 AM, Joubin Houshyar <sun...@gmail.com> wrote:
pm, Salvatore Sanfilippo <anti...@gmail.com> wrote:
and the implementation itself are the only things in sync in this moment.
>
> Hi Salvatore,

Hello,

> I'd appreciate your review of the following pattern for return values
> as I would like to finalize the java interface for release:
>
> Errors:
>
> Any response from Redis beginning with a '-' will be treated as an
> error and will cause an exception in the java client.  Exception will
> have, as its message any bytes from 1.  (ex: "ERR no such key")
>
> ALL methods throw exception (and this may change to an unchecked
> exception once there is sufficient feedback), even methods that can't
> normally fail, such as "ping", since:
>
> ping
> -ERR operation not permitted

So far it's perfect

> This does *not* mean that value responses, such as Bulk or MultiBulk
> that return responses with a '-' in offset 1 will be treated as
> errors.  These will return 'null'.

This is wrong, a bulk reply in the form:

$4
----

is not an error nor NULL, it is just a "----" stirng :)
The first byte must be "-" for a reply to be an error.

> Return values:
>
> 1 - Status Code replies:
>
> Commands returning Status Code will have return type of 'void'.
> Error conditions, if any, are treated per the uniform error handling
> above, by the throwing of an exception.

I'm not sure what "void" is for Java sorry. I guess it just means you
can pass this type around? Btw status codes should return just
strings, if this translates to "void" in Java I've no idea.

> 2 - Integer value replies:
>
> a) Commands returning integer values with number semantics will have
> return types of either int (or long where appropriate).
>
> typical examples:
> int llen (String key) throws ...
> int lrem (String key, byte[] value, int count) throws ..
>
> // we use long here since that is what unix epoch is represented by in
> JVM

Sounds like a good idea. Btw all the integer replies can return a
number as big as a 64bit signed integer.

> //
> long lastsave () throws ...
>
> b) Commands returning integer values with logical conditional
> semantics will have return types of boolean.
>
> // :0 -> false, :1 -> true
> boolean void expire (String key, int ttl) throws ...

That's a good idea for all the APIs more or less.
One should be able to write:

if (redis->operation(....)) {
... the operation suceeded ...

}

> 3 - Bulk and MultiBulk replies:
>
> These methods will return null values for $-1 and *-1, respectively a
> null byte[], and a null List<byte[]>.
>
> $0, maps to a non-null string of length 0
> *0, maps to a non-null List<byte[]> of size 0 (i.e. empty)

Everything is ok.

> A List<byte[]> multibulk value can contain null members. For ex:
> mget nosuchkey foo
> *2
> $-1
> $3
> bar
>
> which maps to a List<byte[]> with list.get(0) returning null, list.get
> (1) returning the byte[] for "bar".

Yep basically what is returned with $-1 as bulk reply is returned as
$-1 as bulk reply element for uniformity.

> Thanks in advance for reviewing this.

Thank you for implementing this :)

Ciao,
Salvatore

>
> /Regards
>
>>
>> Cheers,
>> Salvatore
>>
>> --
>> Salvatore 'antirez' Sanfilippohttp://invece.org
> >
>

[Joubin Houshyar]

> Hello,

Hello Salvatore,

> > This does *not* mean that value responses, such as Bulk or MultiBulk
> > that return responses with a '-' in offset 1 will be treated as
> > errors.  These will return 'null'.
>
> This is wrong, a bulk reply in the form:
>
> $4
> ----
>
> is not an error nor NULL, it is just a "----" stirng :)
> The first byte must be "-" for a reply to be an error.

OK. We're in synch. offset 1 of the first line, as in $-. For bulk,
second line is treated as the cmd specific data and never as control
information.

> > Return values:
>
> > 1 - Status Code replies:
>
> > Commands returning Status Code will have return type of 'void'.
> > Error conditions, if any, are treated per the uniform error handling
> > above, by the throwing of an exception.
>
> I'm not sure what "void" is for Java sorry. I guess it just means you
> can pass this type around? Btw status codes should return just
> strings, if this translates to "void" in Java I've no idea.

Java void is just like C void. Its for the method/function
signature: i.e. this function does NOT return any values.

This is NOT returning "OK" or "PONG" as a status code. It is simply:
either the call worked, or it didn't. If it didn't, expect an
exception to be thrown.


so:

------ begin snip -----------------
// no return values to check.
/ it either worked or an exception will be thrown

try {
redis.ping();
redis.select (2);
redis.flushdb ();
...
}
catch (RedisException e} {
// ex: "ERR operation not permitted"
//
String errmsg = e.getMessage ();
}
------ end ------------------------

I'm *not* entirely convinced/happy that this is ideal, but have
settled on this for the initial release.

I can (but don't yet) hardcode these strings from the redis c source
file and compare
and throw a very specific exception class for every specific redis
error message.

IF you freeze the error responses for beta-0.09, then I'll go ahead
and do that since
it is somewhat more informative and api users can take action based on
the exception
type thrown.

Please *note* that the client is *validating keys* before sending them
to redis:

Legal Key: does not contain (decimal) byte values 10, 13, 32 in any
combination
and is non-empty

bad keys:
""
"foo bar"
"foo\rbar"
" foo"
"foo "

I know redis does not mind leading/trailing spaces in keys at the
protocol level
as your just parsing them away. I do this on the client side to help
protect against
bugs in the user code.

i.e. to guard against bugs such as :

---- begin ----------------------------

String aFooKey = " foobarpaz";
redis.set (key, value);

// ... and then

List<String> myFooKeys = redis.keys ("*foo*");

if(myFooKeys.contains (aFooKey) == false)
{
// confusion: what happened to aFooKey?
// answer: its there but its now "foobarpaz" not " foobarpaz"
}
---- end ----------------------------

> Sounds like a good idea. Btw all the integer replies can return a
> number as big as a 64bit signed integer.

Thanks for the heads up. I'll change them to long then. (int in java
is 32 bit)

> > Thanks in advance for reviewing this.
>
> Thank you for implementing this :)

Its my pleasure! (I'll do my best to have something for you by this
evening so it can go into the beta release.)

/Ciao

>
> Ciao,
> Salvatore

[Joubin Houshyar]

> > Sounds like a good idea. Btw all the integer replies can return a
> > number as big as a 64bit signed integer.
>

(using the redis from git as of yesterday - april 07)


incrby foo 9999999999999
:2147483647

Perhaps I'm being dense but that's a signed 32 bit integer, isn't it?
If that is going to change for beta 09 release to +/-
9,223,372,036,854,775,808 then please let me know as the changing to
long will change the interface and impact some of the internal code.
Thanks.

/R

[Salvatore Sanfilippo]

On Wed, Apr 8, 2009 at 3:50 PM, Joubin Houshyar <sun...@gmail.com> wrote:
>
>
>> > Sounds like a good idea. Btw all the integer replies can return a
>> > number as big as a 64bit signed integer.
>>
>
> (using the redis from git as of yesterday - april 07)
>
>
> incrby foo 9999999999999
> :2147483647

Hello Joubin,

what's bugged here is INCRBY. The argument can't be a 64 bit, so you
can increment at max by 32 bit integer.
But the *incremented* value is indeed 64 bit:

9000s01-2-antirez.0% ./redis-cli incrby mycounter 1000000000
10000000000
m9000s01-2-antirez.0% ./redis-cli incrby mycounter 1000000000
11000000000
m9000s01-2-antirez.0% ./redis-cli incrby mycounter 1000000000
12000000000
m9000s01-2-antirez.0% ./redis-cli incrby mycounter 1000000000
13000000000


Cheers,
Salvatore

>
> Perhaps I'm being dense but that's a signed 32 bit integer, isn't it?
> If that is going to change for beta 09 release to +/-
> 9,223,372,036,854,775,808 then please let me know as the changing to
> long will change the interface and impact some of the internal code.
> Thanks.
>
> /R
>
> >
>