If i consider ZRANGE, it can return elements that match a range. But what if i need the elements that does not match the specified range?

Then i need to make 2 calls to ZRANGE. First get the elements that are before the MIN of the specified range, then get the elements that are after the MAX of the specified range.

I would find usefull to have a NOT option, to specify that i want all elements, except elements that are in this range. It would aggregate 2 ZRANGE queries.

[LIMIT offset count] would still be valid, it would be applied to the final result.

I don't see a way to do it in one call. The syntax of ZRANGE would become:

ZRANGE key min max [BYSCORE|BYLEX] [REV] [NOT] [LIMIT offset count] [WITHSCORES]

The workaround is to do it in 2 calls.

Comment From: itamarhaber

Hello @githubfr

Thanks for making this feature request, it seems like a step in the right direction.

I think that the NOT approach is not useful enough however. IIUC you're asking for a way to run multiple (e.g. 2) ZRANGEs with one command. The first question would be "why?" There would be very little performance gain from that, and the same basic effect can be achieved via a MULTI/EXEC block containing individual ZRANGE calls. The two "gains" that I see, however, are simpler usage and a consolidated reply (as opposed to multiple lists returned by a transaction).

So, given there's merit to a ZMRANGE that accepts multiple ranges, if it is implemented you can have the NOT functionality by specifying the requested ranges to exclude the NOTted ones. Furthermore, you can have multiple NOT-like ranges for even more flexibility (as well as overlapping ranges, ranges and subsranges from these, or any other combination that makes sense or not). Does this make sense?

Comment From: githubfr

Hello Itamar,

It makes sense indeed. The two gains are those that you have noted, they are not negligible, and indeed the NOT keyword in the way i proposed is too limited I agree. ZMRANGE is a great idea, it fits well in the universe of Redis commands, and is powerful from a logical point of view.

If I understood correctly, if it would be implemented maybe the syntax could be:

ZMRANGE key min max [min max...] [NOT min max [min max...]]

also, with it, we can benefit more easily from [BYSCORE|BYLEX] [REV] [LIMIT offset count] [WITHSCORES] than with a MULTI/EXEC where each ZRANGE has its own options.

examples :

myzset: 1 "one" 2 "two" 3 "three" 4 "four" 5 "five"

ZMRANGE myzset 1 5 NOT 2 3 [one -> five] will be added [two -> three] will be excluded

response: "one","four","five"

ZMRANGE myzset 3 4 NOT 2 3 [three -> four] will be added [two -> three] will be excluded response: "four"

ZMRANGE myzset 1 4 NOT 3 5 [one -> four] will be added [three -> five] will be excluded response: "one","two"

Comment From: itamarhaber

I don't quite follow why you insist on having a NOT :) Your examples would be simpler like this IMO:

ZMRANGE myzset 1 (2 (3 5

# This one doesn't actually need ZMRANGE at all
ZRANGE myzset (3 4

# Similarly
ZRANGE myzset 1 (3

Comment From: githubfr

Thank you very much,

I was too focused on the logic of ZMRANGE and forgot about this part of the syntax of ZRANGE that i should have in mind, since it is the subject in fact and is widely commented in the documentation. Using it make the definition of the ranges easier to express i agree, so simpler that indeed the last 2 of my examples don't need ZMRANGE. But that doesn't change the substance.

ZMRANGE myzset 1 (2 (3 5 is nice as if this command already existed.

Comment From: itamarhaber

Ok, cool. I took the liberty to rename the subject.

So now we're back to square one - do we want a variadic (dynamic arity) variant of ZRANGE, or would MULTI/EXEC suffice. Personally, I'm not entirely sold on the idea of adding this new command despite the "gains", but I'd love to get more feedback from everyone.

Comment From: githubfr

Hello Itamar,

You are right, it's everyone's opinion that counts and after 2 hours I don't think the idea will raise crowds, but also maybe because it is a small add that anyone don't see really the use. MULTI/EXEC is ok, but for me it's a bit of a cannon to kill the fly for this need. I like the pure logic aspect of this concise and effective variation of ZRANGE. At the beginning the idea was not clear, but you have shown all the logic in it and there is nothing to do more to convince people. Anyway, if you must abandon the idea, which I think is probable, i understand and it won't change much I agree.