SET command overwrites complex data structures (sets, hashes ...)

[GoogleCodeExporter]

What steps will reproduce the problem?

redis> sadd foo 1
(integer) 1
redis> smembers foo
1. "1"
redis> set foo bar

What is the expected output?

(error) ERR Operation against a key holding the wrong kind of value

What do you see instead?

OK

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

version 2.1.2 on os x (snow leopard)

Please provide any additional information below.

i find this behaviour inconsistent, as calling for example hash
commands on a key holding a string always fail. i was expecting 
to have to delete the key to switch its type to string.

Original issue reported on code.google.com by t...@lossen.de on 9 Aug 2010 at 3:31

[GoogleCodeExporter]

Good point, this is more consistent technically speaking... my fear is that's 
going to break a lot of existing code. It would be cool to have some feedback 
about this, and to understand if it's a good idea to do this change, if it's a 
good idea to do this in 2.x or if it's better to wait for 3.0 to break things 
in a so strong way.

Ciao,
Salvatore

Original comment by anti...@gmail.com on 9 Aug 2010 at 7:14

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Ok, actually is not so trivial, now I remember my original reasoning:

{{{

>> a = [1,2,3]
=> [1, 2, 3]
>> a.push(4)
=> [1, 2, 3, 4]
>> a.match("foo")
NoMethodError: undefined method `match' for [1, 2, 3, 4]:Array
    from (irb):3
>> a = "foo"
=> "foo"
}}}

What happens here is that SADD, or HSET and so forth are operations against a 
value that already exists, and is automatically created if needed...

Instead SET is: overwrite the key with this new values.

We could have the same operator for lists for instance:

SETLIST key A B C D E

So I think that after all the current behavior is ok :)

Original comment by anti...@gmail.com on 9 Aug 2010 at 7:30

[GoogleCodeExporter]

ok, i get your point -- redis keys are like variables. although i think this 
metaphor breaks down at other points, where redis has different semantics:

redis> sadd x 1
(integer) 1
redis> srem x 1
(integer) 1
redis> smembers x
(empty list or set)
redis> hset x a 1
(integer) 1
redis> 

i do not know any programming language where an empty set is automatically 
converted into an empty hash ;)

Original comment by t...@lossen.de on 10 Aug 2010 at 5:54

[GoogleCodeExporter]

Tim, for SREM semantic when there are no longer elements the key is deleted:

redis> sadd x 1
(integer) 0
redis> srem x 1
(integer) 1
redis> exists x
(integer) 0
redis> 

So actually there is no inconsistency here. Before Redis 2.0.0 it used to be 
different (empty aggregates where allowed) and the result was a type mismatch 
error indeed.

Cheers,
Salvatore

Original comment by anti...@gmail.com on 27 Aug 2010 at 11:30

• Changed state: WontFix