I was attracted to Redis by the ZUNION and ZINTER commands.

Installing it, I found these were recently removed in favor of ZUNIONSTORE and ZINTERSTORE.

For my use case, I would prefer to have the result of the union and intersection of sorted sets be returned directly rather than stored.

In other words, it would be great to have both ZUNIONSTORE and ZUNION, and have both ZINTERSTORE and ZINTER.

In the same way that there is both SUNION and SUNIONSTORE, and both SINTER and SINTERSTORE.

I was previously implementing these features myself using Lua extensions to TokyoTyrant. If the above could be supported, that would hit the nail on the head. It would be a real shame to have to wrap ZINTERSTORE temp ..., ZRANGE temp, DEL temp in a MULTI block.

I doubt I would use a MULTI block to do this. I would probably use unsorted sets instead. But that would defeat the whole point as I would lose the ability to score my objects by timestamp and retrieve recently updated objects, which would be a ridiculously massive win.

Thanks for the great work. I hope these changes can be incorporated! They seem to be basic building blocks. The programmer can be responsible for the performance implications of using them (by intersecting only secondary indexes etc.), rather than not having them present. For instance, there are use-cases where it makes more sense to compute intersections on demand rather than pre-compute them. In the case of intersecting small secondary indexes for the purposes of restricting access to objects by user, it makes more sense to compute than pre-compute since pre-computing unique authorization sets (and subsequently updating these for every object update) for every user would require vastly more storage and slow down updates as a function of the number of users with access to an object.

Another case for adding back ZINTER and ZUNION:

Redis is probably more network-bound and memory-bound than cpu-bound, so that moving small intersection computations out to the application layer or forcing them to be pre-computed would hurt rather than help performance.

Small sorted set intersections should be possible without the interface forcing you to pre-compute. If larger sorted set intersections are required, then these can be pre-computed.

This was a simple command rename, not modification.

In sorted sets returning the elements after the intersection does not make too much sense as there is the score information that gets lost.

Btw it's up to you, you can trivially turn every *STORE command in an equivalent non *STORE command in this way:

{{{ MULTI ZINTERSTORE tmpkey ... ZRANGE tmpkey ... DEL tmpkey }}}

Note that tmpkey can be used again and again as we are inside the contest of MULTI/EXEC.

Cheers, Salvatore

This was a simple command rename, not modification.

In sorted sets returning the elements after the intersection does not make too much sense as there is the score information that gets lost.

Btw it's up to you, you can trivially turn every *STORE command in an equivalent non *STORE command in this way:

{{{ MULTI ZINTERSTORE tmpkey ... ZRANGE tmpkey ... DEL tmpkey }}}

Note that tmpkey can be used again and again as we are inside the contest of MULTI/EXEC.

Cheers, Salvatore

This was a simple command rename, not modification.

In sorted sets returning the elements after the intersection does not make too much sense as there is the score information that gets lost.

Btw it's up to you, you can trivially turn every *STORE command in an equivalent non *STORE command in this way:

{{{ MULTI ZINTERSTORE tmpkey ... ZRANGE tmpkey ... DEL tmpkey }}}

Note that tmpkey can be used again and again as we are inside the contest of MULTI/EXEC.

Cheers, Salvatore

I just started using Redis and one of my use cases is the do intersections between sorted and unsorted lists. If I could do this with SINTER I would be happy - but it doesn't seem to accept sorted sets. So I'm using sorted sets which take unsorted sets as inputs. While I can see the value in storing this, there are many use cases where I don't need to store it and it seems silly to have to hack it creating a store, getting the range and deleting it. These commands will get written to the log and replicated, written to the AOF, etc. Why?

As far as the score information - why should it be any different from a zrange - give zinter the option of withscores? It'll then return the scores are not.

I think these options make sense anyway - but my problem would be solved also if sinter allowed sorted sets as arguments - is that a possibility?