[FEATURE REQUEST] Quering by list of keys (patterns) like in SORT but without sorting

[GoogleCodeExporter]

SORT is very powerful command when used with "GET pattern" but what if i 
don't need sorting? If some list, set or just string value holds part of 
key name of another value and is already sorted in necessary order (or 
produced from previous SORT call, or just don't need sorting overhead)? Is 
any way to do the same as SORT? E.g. list A contains values 4,7,1,3 and I 
need to get key_4, key_7, key_1, key_3 in that order? 
Such feature is also very good for SUNION/SINTER/SDIFF to avoid storing 
result in some new key (even when result is stored, I cannot get what I 
need if I don't need sorting (because don't want additional overhead), but 
just need names of set members for building key names): SINTER key1 key1 
GET pattern.
And for LRANGE: LRANGE key start end GET pattern
And for all similar commands which return multiple elements.
Or it could be one command, say QUERY, which could be used as prefix to 
described commands (LRANGE,SINTER etc).

Original issue reported on code.google.com by yurasfro...@gmail.com on 11 May 2010 at 6:58

[GoogleCodeExporter]

For SORT, if you don't need sorting, you can use "BY nosort".  See 
http://code.google.com/p/redis/wiki/SortCommand#Not_Sorting_at_all

Not sure about for the other situations you list, but you can probably use SORT 
with 
the STORE option to put the values in a temporary key.

Original comment by boulton.rj@gmail.com on 24 May 2010 at 9:55

[GoogleCodeExporter]

SORT actually can get values by keys stored in a set, list or sorted set. I 
don't think this feature should be generalized for SUNION, SINTER, SDIFF to 
allow them retrieveing values without storing results under temporary key (as 
described in original description for this feature request) as it would make 
memory management too complex. I'm sure internaly it would require allocation 
of memory for this temporary result. So there is nothing bad in that we do the 
same explicitly.

To get this feature request back to live I'd like to report about the problem 
with using SORT with sorted set. When we use SORT with 'BY nosort' against 
sorted set the order of values we have is not guaranteed to be sorted by scores 
(i.e. the order which is expected from values in sorted set) refer to mail 
thread 'Strange behavior of SORT against sorted sets' 
http://groups.google.com/group/redis-db/browse_thread/thread/f41e601c4e3e49fc 
for details.

I'm not sure how SORT works with lists but in general I would expect SORT to 
keep order of values from sorted sets or lists when it is used with 'NO sort' 
in either case if it is used to get just values or values by keys with 'GET 
obj_*' like syntax.

Original comment by Alfiia.M...@gmail.com on 6 May 2011 at 3:14

[GoogleCodeExporter]

This is my patch to the issue discussed in the topic 
http://groups.google.com/group/nosql-databases/browse_thread/thread/f41e601c4e3e
49fc/b7a56e9427a8cc49#b7a56e9427a8cc49

I simply replaced the iterate through the directory to iterate through the list.

sort.c line 234

replace:
        dict *set = ((zset*)sortval->ptr)->dict;
        dictIterator *di;
        dictEntry *setele;
        di = dictGetIterator(set);
        while((setele = dictNext(di)) != NULL) {
            vector[j].obj = dictGetEntryKey(setele);
            vector[j].u.score = 0;
            vector[j].u.cmpobj = NULL;
            j++;
        }
        dictReleaseIterator(di);
to:
        zskiplist *zsl = ((zset*)sortval->ptr)->zsl;
        zskiplistNode *node = zsl->header->level[0].forward, *next;
        while(node) {
            vector[j].obj = node->obj;
            vector[j].u.score = 0;
            vector[j].u.cmpobj = NULL;
            j++;
            next = node->level[0].forward;
            node = next;
        }

Original comment by alexandr...@gmail.com on 29 Jun 2011 at 3:09