Starting with Redis 3.0.3 the EXISTS command is variadic so that it is
possible to check for the existence of multiple keys in one request,
with the server returning the number of keys found.
This change could break codebases relying on strict comparison (===)
against a boolean value, but just doing $redis->exists('key') == TRUE
is totally fine.
This change is needed due to some internal changes in one of the
latest minor releases of PHPUnit 4.x that essentially broke how we
were checking for the required Redis version from method annotations.
Serializing an instance of a redis-cluster connection with its nodes
can take more than 1 seconds on extremely slow hardware.
See issue #220 for reference.
When iterating a sorted set containing integer members, our iterator
abstraction based on ZSCAN was always returning "0" as a member value
after the first $member => $score pair because of a wrong assumption
on how the PHP function array_shift() (used internally to advance to
the next pair in our buffered response to ZSCAN) works.
Fixes#216.
Previously there was a bug in Redis that returned the wrong command
in -ERR messages when passing an invalid expire time with SETEX and
PSETEX. Now that the bug has been fixed and that travis-ci uses a an
updated version of Redis, our test suite turned red.
Redis 3.0 does not really change much in terms of commands (most of
the ones implemented in the "unstable" branch have been backported to
the "2.8" branch after all) aside from a few cluster-related ones, so
we can bump the default version without worries.
This change actually had a positive impact on the design of the whole
internals for clustering which is now cleaner and easier to maintain.
It is still far from perfect, but we also have to keep performances in
consideration so we can say that we ended up with a good compromise.
Previously Predis assigned an hash to each command instance which was
computed from its key, now we changed approach and the library caches
the slot assigned to each command. This works for both our client-side
sharding cluster and the upcoming redis-cluster, but the former is the
one that needed most changes.
The PredisCluster aggregate connection now only takes an instance of
StrategyInterface, which in turn wraps the chosen distributor. After
all, in order to be able to calculate the assigned slot for a command
or key, the cluster strategy must have access to the distributor that
manages the distribution of the whole keyspace. Nothing really changes
in terms of configurability as it is still possible to decide which
distributor to use for client-side sharding, it is simply different:
$distributor = new Predis\Cluster\Distribution\KetamaRing();
$strategy = new Predis\Cluster\PredisStrategy($distributor);
$cluster = new Predis\Connection\Aggregate\PredisCluster($strategy);
As for the RedisCluster aggregate connection, the only change is that
the mathematical operation of calculating the assigned slot from a key
has been completely moved inside the cluster strategy instance.
The strategy for redis-cluster does not use external distributors so
trying to StrategyInterface::getDistributor() will throw an exception.
This may change in future releases, but this is not a priority since
redis-cluster relies on a fixed, well-defined distribution mechanism.
This optimization makes it possible to fetch the slots map directly
from the server indicated by the -MOVED response eliminating the need
to use a random node in the pool, which in turn could require Predis
to open a new and useless connection.
This is a more sane default as it allows users to indicate only a few
servers of the whole cluster composition, while it previously required
a more complex configuration of the client using client options.
This feature can be disabled using the "enableAutoSlotsMap()" method.
Daniele Alessandri
Michal Humpula
nicchap
Ruben de Vries