Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with
or
.
Download ZIP

Loading…

sismember key member member member ... #846

Closed
zuroc opened this Issue · 8 comments

6 participants

@zuroc

I think is necessary to add command like this :

sismember key member member member ...

@AllenDou

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

try it.

@DivineTraube

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

@AllenDou

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.

@DivineTraube

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.

@antirez
Owner

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
@grddev

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)

@djanowski

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

@grddev

@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
Something went wrong with that request. Please try again.