The problem/use-case that the feature addresses

The SORT command doesn't support '*' as a glob style GET pattern for hash field name. If I save ages of persons in a hash (person id as field, age as value), and person ids in a set, and I want to get all (person, age) pairs. There's no easy way to achieve that. This SO question states a similar problem.

Description of the feature

If the SORT command support '*' as a glob style GET pattern for hash field name, we can simply solve the problem with the following command: 

sort ids by nosort get # get ages->*

Alternatives you've considered

So far, we can only achieve the goal with Lua script, or save each person's age in a dedicated key or hash.

Additional information

None

Comment From: itamarhaber

Hello @sewenew - so good to see you again :)

Your suggestion makes sense to me in terms of functionality and syntax, and I don't think that making this change will break the world (although there may be a collision if someone has a hash with a field named '*' perhaps). It would be good to have additional feedback from the community however.

A word of caution: SORT is easily the most complex/least usable command in Redis, to the extent it feels to me like something foreign. I consider it an "anti-pattern", if only because of its implicit multi-key nature. In most, if not all, cases I recommend avoiding it.

Comment From: sewenew

Yes, I totally agree that SORT is complex, and also, if the data is too large, it might block Redis for some time.

Comment From: zuiderkwast

Could we simply allow the fields of a hash to be used as a set? That is, can we make the set type read commands accept hashes?

This is what the SO question linked above suggests.

Comment From: itamarhaber

Hash-as-set is definitely logical, but I still want to keep thinking about SORT as semi-deprecated. That said, I wouldn't reject a PR just because of that.

Comment From: Telofy

My 2 cents ^.^:

I want to store an orderbook in a hash, so the mapping is price -> volume. There are way more writes than reads. Hence I'd love to be able to do one of the following in this order:

  1. Use sort to retrieve the first 10 levels of the book (both field name and value) asc or desc.
  2. Have a sorted hash datatype (not ideal because adds will be in O(n) rather than O(1), and I'd prefer to keep the complexity on the read side). This could also be conceived of as an inert annotation for a sorted set entry, a bit of data that is used neither for sorting nor for uniqueness.
  3. Some complicated sort magic with sets that are copies of the hash keys and use get to reattach the values or whatever.