I'm a little confused by the behavior of HSET.
Assuming a key named "test_hash" and fields named "foo1" and "foo2"
the following occurs:
1.) HSET test_hash foo1 test_value
This returns 1 as expected.
2.) HSET test_hash foo2 test_value2
This returns 1 as expected.
3.) HSET test_hash foo1 test_value_new
This returns 0 which to me indicates the operation failed. However...
4.) HGET test_hash fool1
Returns test_value_new.
Why does #3 return a 0 which indicates a failure?
-J
Maybe it's not about failing but about overwriting? Like, 0 - there
was a key with this name already.
In fact HSET cannot fail.
--
Best Regards,
Konstantin Merenkov
-J
> --
> You received this message because you are subscribed to the Google Groups "Redis DB" group.
> To post to this group, send email to redi...@googlegroups.com.
> To unsubscribe from this group, send email to redis-db+u...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/redis-db?hl=en.
>
>
I was right, documentation says: "If the field already exists, and the
HSET just produced an update of the value, 0 is returned, otherwise if
a new field is created 1 is returned."
Anyway, check the doc, it describes return values for all functions -
http://code.google.com/p/redis/wiki/CommandReference
-J
Sent via iPhone
Is your e-mail Premiere?
What's the general doc on Integer Replies?
Many commands return 0 or 1 depending or whether the key existed or
not, so I don't see the inconsistency. If the command really failed
(like you provided the wrong amount of arguments), Redis will reply
with an error (-ERR).