X-Git-Url: https://git.saurik.com/redis.git/blobdiff_plain/47868511523c855799c315977b5d480f6f15a4be..ab72b4833d2054231437acccec36f32f07290075:/doc/SortCommand.html?ds=sidebyside diff --git a/doc/SortCommand.html b/doc/SortCommand.html index f89fd7c2..7ed3eb01 100644 --- a/doc/SortCommand.html +++ b/doc/SortCommand.html @@ -16,7 +16,7 @@
An interesting pattern using SORT ... STORE consists in associatingan EXPIRE timeout to the resulting key so that inapplications where the result of a sort operation can be cached forsome time other clients will use the cached list instead to call SORTfor every request. When the key will timeout an updated version ofthe cache can be created using SORT ... STORE again.
Note that implementing this pattern it is important to avoid that multipleclients will try to rebuild the cached version of the cacheat the same time, so some form of locking should be implemented(for instance using SETNX).-
It's possible to use BY and GET options against Hash fields using the following syntax:
+SORT mylist BY weight_*->fieldname +SORT mylist GET object_*->fieldname ++
The two chars string -> is used in order to signal the name of the Hash field. The key is substituted as documented above with sort BY and GET against normal keys, and the Hash stored at the resulting key is accessed in order to retrieve the specified field.