« Changelog History


Predis v1.1.0 Release Notes

Release Date: 2016-06-02 // almost 8 years ago

  • Introduction

    🚀 This is a minor release of Predis packed with new features and various improvements of existing ones. As usual you can read the CHANGELOG for a schematic list of the changes. Thanks to anyone who provided feedback, especially on the new features, and proposed changes implemented in this release! Starting today we also have a chat room on Gitter, for now it's kind of an experiment but we'll see on the long run if it'll prove to be useful.

    IMPORTANT : if you are using "predis/predis": "dev-master" in composer.json then replace the requirement with tagged releases in the v1.1 branch as soon as possible! Starting today the master branch will host the development of the next major version of Predis, the first few commits containing some major breaking changes will land there in a matter of days meaning that if you won't replace dev-master your applications may (and most likely will) fail all of sudden.

    NOTE : speaking of Predis v2.0 we are aiming to bump the minimum required version of PHP to 5.5.9 (most likely to happen) and drop PEAR for distribution (still to be decided). The v1.1 branch will be maintaned for fixes so if you are stuck with PHP 5.3 and 5.4 you don't have too much to worry about for a while. If you have anything to say on the matter please join the discussion by leaving a comment or a reaction on #335, we need your feedback!

    🆕 New features

    Support for redis-sentinel is finally baked into Predis! As usual configuring the client is easy, it's just a matter of providing a list of sentinel servers and configure the client accordingly:

    $parameters = ['tcp://127.0.0.1:5380', 'tcp://127.0.0.1:5381', 'tcp://127.0.0.1:5382'];$options = ['replication' =\> 'sentinel', // use the appropriate replication backend'service' =\> 'mymaster', // provide a service name for discovery];$client = new Predis\Client($parameters, $options);

    See replication_sentinel.php for a complete example.

    Redis servers protected by SSL-encrypted connections can be accessed by using the tls or rediss scheme in connection parameters along with SSL-specific options in the ssl parameter (array):

    // Parameters in the form of a named array$parameters = ['scheme' =\> 'tls','host'=\> '127.0.0.1','ssl'=\> ['cafile' =\> '/path/to/redis.pem','verify\_peer\_name' =\> true,],];// Parameters in the form of an URI string$parameters = 'tls://127.0.0.1?ssl[cafile]=/path/to/redis.pem&ssl[verify\_peer\_name]=1';

    0️⃣ Implemented the ability to specify default connection parameters for aggregate connections with the new parameters client option. These parameters augment the usual user-supplied connection parameters (but do not take the precedence over them) when creating new connections and they are mostly useful when the client is using aggregate connections such as redis-cluster and redis-sentinel as these backends can create new connections on the fly based on responses and redirections from Redis:

    $parameters = ['tcp://127.0.0.1:6381', 'tcp://127.0.0.1:6382', 'tcp://127.0.0.1:6383'];$options = ['cluster' =\> 'redis',// New connections to Redis will be created using the same following parameters:'parameters' =\> ['database' =\> 5, 'password' =\> $secret],];$client = new Predis\Client($parameters, $options);

    Predis\Client implements the IteratorAggregate interface making it is possible to iterate over traversable aggregate connections and get a new client instance for each Redis node:

    $client = new Predis\Client($parameters, ['cluster' =\> 'redis']);foreach ($client as $nodeClient) {$nodeClient-\>flushdb(); // executes FLUSHDB on each node of the cluster}

    🔄 Changes

    • 0️⃣ The default server profile for the client now targets Redis 3.2.
    • 🚚 Responses to the following list of commands are not casted into booleans anymore but instead the original integer value of the response is returned: SETNX, MSETNX, SMOVE, SISMEMBER, HSET, HSETNX, HEXISTS, PFADD, EXISTS, MOVE, PERSIST, EXPIRE, EXPIREAT, RENAMENX. This change does not have a significant impact unless when using strict comparisons (=== and !==) on the returned value.
    • 🚀 Using unix:///path/to/socket in URI strings to specify a UNIX domain socket file is now deprecated in favor of the format unix:/path/to/socket (note the lack of the double slash after the scheme) and will not be supported starting with the next major release.
    • 👻 The client throws exceptions when Redis returns any kind of error response to initialization commands (the ones being automatically sent when a connection is established, such as SELECT and AUTH when database and password are set in connection parameters) regardless of the value of the exception option.
    • 🚚 Iterating over an instance of Predis\Connection\Aggregate\RedisCluster will return all the connections mapped in the slots map instead of just the ones in the in-memory pool. This change makes it possible, when the slots map is retrieved from Redis, to iterate over all of the master nodes in the cluster. When the use of CLUSTER SLOTS is disabled via the useClusterSlots() method, the iteration returns only the connections with slots ranges associated in their parameters or the ones initialized by -MOVED responses in order to make the behaviour of the iteration consistent between the two modes of operation.

    👌 Improvements

    Non-boolean string values passed to the persistent connection parameter can be used to create different persistent connections to the same host-port pair:

    // $parameters1 and $parameters2 will create two different persistent connections:$parameters1 = "tcp://127.0.0.1:6379?persistent=first";$parameters2 = "tcp://127.0.0.1:6379?persistent=second";

    Note that this feature was already present in Predis but required both persistent and path to be set as illustrated by #139, this change was needed to prevent confusion with how path is used to select a database when using the redis scheme.

    Various improvements to Predis\Connection\Aggregate\MasterSlaveReplication (the "basic" replication backend, not the new one based on redis-sentinel):

    • When the client is not able to send a read-only command to a slave because the current connection fails or the slave is resyncing (-LOADING response returned by Redis), the backend discards the failed connection and performs a new attempt on the next slave. When no other slave is available the master server is used for read-only commands as last resort.
    • It is possible to discover the current replication configuration on the fly by invoking the discover() method which internally relies on the output of the command INFO REPLICATION executed against the master server or one of the slaves. The backend can also be configured to do this automatically when it fails to reach one of the servers.
    • Implemented the switchToMaster() and switchToSlave() methods to make it easier to force a switch to the master server or a random slave when needed.

    Other links