- Documentation
- Reference manual
- Packages
- Redis -- a SWI-Prolog client for redis
- library(redis): Redis client
- redis_server/3
- redis_connect/1
- redis_connect/3
- tls_verify/5
- sentinel_slave/4
- redis_disconnect/1
- redis_disconnect/2
- redis/2
- redis/3
- redis/1
- redis_write/2
- redis_read/2
- redis_get_list/3
- redis_get_list/4
- redis_set_list/3
- redis_get_hash/3
- redis_set_hash/3
- redis_array_dict/3
- redis_scan/3
- redis_sscan/4
- redis_hscan/4
- redis_zscan/4
- redis_current_command/2
- redis_current_command/3
- redis_property/2
- redis_subscribe/4
- redis_subscribe/2
- redis_unsubscribe/2
- redis_current_subscription/2
- library(redis): Redis client
- Redis -- a SWI-Prolog client for redis
redis(Connection, Command, _)
and
second, it can be used to exploit Redis pipelines and transactions.
The second form is acticated if Request is a list. In
that case, each element of the list is either a term Command -> Reply
or a simple
Command. Semantically this represents a sequence of redis/3
and
redis/2 calls. It differs in the
following aspects:
- All commands are sent in one batch, after which all replies are read. This reduces the number of round trips and typically greatly improves performance.
- If the first command is
multi
and the lastexec
, the commands are executed as a Redis transaction, i.e., they are executed atomically. - If one of the commands returns an error, the subsequent commands are still executed.
- You can not use variables from commands earlier in the list for commands later in the list as a result of the above execution order.
Procedurally, the process takes the following steps:
- Send all commands
- Read all replies and push messages
- Handle all callbacks from push messages
- Check whether one of the replies is an error. If so, raise this error (subsequent errors are lost)
- Bind all replies for the
Command -> Reply
terms.
Examples
?- redis(default, [ lpush(li,1), lpush(li,2), lrange(li,0,-1) -> List ]). List = ["2", "1"].