sismember key member member member ... #846

zuroc opened this Issue Dec 23, 2012 · 8 comments

6 participants


I think is necessary to add command like this :

sismember key member member member ...


@zuroc you can do it with lua script,
local member={}
local key=KEYS[1]
local ret={}
for i = 2,5 do
member[i-1] = KEYS[i]
for k,v in pairs(member) do
return ret" 4 set 111 222 344

try it.


Imho, almost everything can be achieved using a Lua script. The additional parameters for SISMEMBER are a useful feature anyway.


yes, you are right, but i think one of the most important principle of redis is Simple is best, redis only support some foundational commands, if any user want to implement complicated function, then try lua scripting, that's why @antirez introduce lua to redis, i think.


You are absolutely right. But introducing this command doesn't add any complexity, since the command already exists. It just needs to take additional parameters. SADD does for instance already take these optional additional parameter keys since version 2.4. So giving a similar operation signature to SISMEMBER would only be consistent.


The problem with turning unary command into variadic versions is the return value.

Consider this, currently you get :0 or :1 as a reply for SISMEMBER.

If you turn this into variadic, you need to return an array of 1/0, so you break the return value. So you may think to:

  • Return an array anyway. This breaks the API and returns a single-item array for the single-arg form. Not cool.
  • Return an array only if there are two or more args. This makes generating commands in a programmatic way hard.

So in all this cases, you need a new command like MSISMEMBER, that sounds like a bit of an overload considering it's trivial with scripting.

@antirez antirez closed this Feb 8, 2013

Admittedly a little late to the party, but a backwards-compatible return value would be to just return the count of matching keys (making it consistent with the behavior of SADD)


@grddev Unless I'm missing something, you usually want to know which members exist and which don't, so a mere count wouldn't add any value.


@djanowski That is a fair point, although I disagree for two reasons;

  • what about all operations that only need partial information. For example, if I only need to know that one of N items is in the set, or half of them, or all of them;
  • why is this not a problem for SADD? Why would it make more sense to return the count in a modifying operation and at the same time not in a querying operation.

For my application, I needed the count of already present members (without updating the set). It seems counter-intuitive to have to resort to Lua script for the querying operation when the modifying operation is built in.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment