Why redis provides SET and MSET commands separately?

[tjuer]

In my opinion, SET is just a special case of MSET, we should be able to merge them into one command.

I wonder why don't just extend the functionality of 'SET' command but introduce a new MSET command.

 

Similarly, HSET/HMSET commands also come up with this problem.

 

 

[Didier Spezia]

I guess the main reason is historical.

Generalization of commands with variadic parameters is a late addition to Redis.

Regards,

Didier.

[Salvatore Sanfilippo]

SET/MSET, historical reasons.

HSET/HMSET, historical error...

With 3.0 I hope to fix a few API mistakes. In general I think we
should have M-commands mostly only for *read* operations, because the
desired return value is different from the point of view of the
client, example:

foo = GET('bar'); // should return a String object.
items = MGET('foo','bar'); // should return an Array.

So the first translates into a bulk reply, and the latter into a multi
bulk, otherwise you would be supposed to do something like:

foo = GET('bar')[0], or .first or something like that. I don't like
it, better to have a less generic API but optimize for the simple
common case.

For write operations most of the time it is possible to find an
unique, backward compatible, return value that makes sense.

Salvatore

> --
> 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.

--
Salvatore 'antirez' Sanfilippo
open source developer - VMware

http://invece.org
"We are what we repeatedly do. Excellence, therefore, is not an act,
but a habit." -- Aristotele