This is from the latest unstable branch. If a slave is set to readonly, SORT is considered a writing command even if you're not storing the result.
connect to a slave and then: redis 127.0.0.1:6378> sort foo (error) READONLY You can't write against a read only slave.
IMHO This should not happen unless you want to store the result.
Comment From: kushwiz
this is an issue.. sort on slaves should work.. i wonder why this has not been fixed, been over a year already..
Comment From: charsyam
see this - https://github.com/antirez/redis/pull/1286
Comment From: eduardobr
Bumped into the same issue today. My use case is a simple SORT someSetKey BY nosort GET "keyPrefix:*->hashName"
This is just a lookup from keys contained in a Set. A new, read-only command dedicated to this would be interesting.
Comment From: madolson
Yeah, that is a bit silly. I suppose the idiomatic way would be to implement a SORT_RO variant that doesn't allow the store component. (similar to GEORADIUS_RO) Let me check to see if there are any other weird commands like this. EDIT: doesn't look like there are any other weird commands like this.
Comment From: eduardobr
I'll try a PR with a SORT_RO... Just found strange the uncommon underscore in GEORADIUS_RO
Comment From: dvirsky
This bug is from almost a decade ago, and while it was never officially announced, SORT has been kind of been unofficially semi-deprecated. I kinda feel that SORT should not be used, and might be a good first precedent to be the first command to be taken out of Redis. @yossigo WDYT?
Comment From: madolson
@dvirsky I'm pretty sure we would try to deprecate KEYS first :) What is the story about trying to deprecate it, I don't know much about that, and I know a couple of people who find it useful.
@redis/core-team SORT_RO, yes or no?
@eduardobr I would recommend holding off on a PR until the other folks way in.
Comment From: dvirsky
@madolson Salvatore treated it as a bad direction he went in in the early days - since it's very inefficient and in a way worse than KEYS - and sort of quietly ignored it. I remember I sent a CL improving it and he was like "Nope, not going to invest in it". But it was also never really deprecated.
Comment From: oranagra
I also spoke to Salvatore several times about the inconsistency of SORT with GEORADIUS / _RO (and with the SUNION / SUNIONSTORE family). Since then, we actually deprecated GEORADIUS in favor of GEOSERCH and GEOSEARCHSTORE, and if we do something with SORT, maybe that's what we should do. i.e. other than the command flags (being read or write command), there's also the matter of easily finding the key names in the arguments.
other issues with SORT is all the BY and GET argument, which make it unfriendly to sharding.
I'm not certain what's the exact course of action, but i do agree we wanna do something for 7.0 that will "deprecate" the current one and add better alternatives (i don't think we just wanna consider it deprecated without an alternative, or keep it like it is).
Comment From: eduardobr
@madolson Salvatore treated it as a bad direction he went in in the early days - since it's very inefficient and in a way worse than KEYS - and sort of quietly ignored it. I remember I sent a CL improving it and he was like "Nope, not going to invest in it". But it was also never really deprecated.
When you say inefficient, do you remember which parts? For example, I use it like this: SORT client:123:accounts BY nosort GET "account:*->ahashfield"
Where client:123:accounts is a set
Comment From: madolson
For reference: https://github.com/redis/redis/issues/2876, here is the issue with SORT and cluster.
I never really liked that is the only "collections" API that Redis provides. I also don't think we can deprecate it without providing an alternative.
@eduardobr It's just O(N*Log(N)) where N is the number of elements in the object. For a redis command that is slow, most operations are much faster. I don't think there is anything strictly wrong with that time complexity for infrequent operations though.
Comment From: yossigo
@dvirsky I will be happy to see SORT going away, but agree it's more likely we'll get rid of other deprecated commands first (that have an alternative).
BTW specifically nosort is a real hack and abuse of SORT and something that should be more easily be solved in better ways.
Comment From: eduardobr
Enriching the discussion: https://github.com/redis/redis/pull/9299#issuecomment-890599389