Open GoogleCodeExporter opened 8 years ago
I agree that this should be consistent. Thanks for noticing.
The reason it is not right now is that it shares timeout code with the regular
blocking pops, which in fact do emit a null multi bulk on timeout. In my
opinion this is only cosmetic, since both the null bulk and null multi bulk
means some kind of null value (unlike the empty bulk/string vs the empty multi
bulk/array). Does the client you use return different objects for these two
types of null replies?
Original comment by pcnoordh...@gmail.com
on 30 Aug 2011 at 3:57
I've only used the redis-rb client before, which does return nil for any
null reply.
The reason I'm noticing the issue now is that I'm writing my own client in a
statically typed language, Haskell. Because of type inference and a mapping
that I define from Redis reply types to common Haskell types, if I declare
that my client's `brpoplpush` function returns the common type `IO (Maybe
String)` (i.e., a string that can be null), then it can be inferred at
compile time that a bulk reply should be read from the socket.
I worked around the BRPOPLPUSH issue by changing my type mapping so that `IO
(Maybe String)` can be coerced from either a bulk reply or a null multi-bulk
reply. However, having a guaranteed reply type for each command is a nice
property, and I figured that it would be worth pushing for if BRPOPLPUSH is
the only exception.
Original comment by teb...@gmail.com
on 30 Aug 2011 at 8:54
Original issue reported on code.google.com by
teb...@gmail.com
on 29 Aug 2011 at 8:59