snehac-miner / redis

Automatically exported from code.google.com/p/redis
0 stars 0 forks source link

Inconsistent behavior on key type modification #91

Closed GoogleCodeExporter closed 8 years ago

GoogleCodeExporter commented 8 years ago
What steps will reproduce the problem?
1. SADD foo 3 bar
2. SET foo 6 foobar
3. SADD foo 7 whynot?

What is the expected output? What do you see instead?
This behavior is not a bug as it is per current spec., but it is inconsistent.

Redis allows the user to (perhaps carelessly) set a non String key to string 
using SET but 
disallows changing string key (for example) to set.   

It would be more consistent if key type change policy is uniform across key 
types, and it would 
also help end users develop more robust applications.

What version of the product are you using? On what operating system?
any

Original issue reported on code.google.com by SunO...@gmail.com on 5 Nov 2009 at 9:41

GoogleCodeExporter commented 8 years ago
Hello SunOf27,

actually my point of view is a bit different. SET is a "set this key to this 
value"
operation, that is very different from, for instance, SADD. Forgot for a moment 
that
SADD can create a Set, actually it is an operation against a set, that is, "add 
this
element into a set". If Redis were a dynamic programming language like Ruby:

{{{
a = [1,2,3]
b = 5; # That's like SET
b.push("foo"); # That is clearly an operation against the wrong type
}}}

If we had a MKSET operation to create a new set, it would be exactly like SET,
removing the old value, but we don't have one. The only way to create a set is 
just
to use a special behavior of SADD that will create a Set before to add the 
element
when called against a non existing key.

Cheers,
Salvatore

Original comment by anti...@gmail.com on 5 Nov 2009 at 11:39

GoogleCodeExporter commented 8 years ago

Original comment by anti...@gmail.com on 23 Aug 2010 at 3:33