Predis is a flexible and feature-complete PHP (>= 5.3.2) client library for Redis.
This is a major release and it is not backwards compatible with the v0.7.x series due to the fact that some namespaces and classes have been renamed or moved and a few parameters and client options have been modified. What follows is an overview of the new features and major changes introduced with this new release, for a more in-depth list of changes please read the CHANGELOG.
New features and changes
Support for Redis versions and features
The default server profile is now 2.6
which is the current stable branch of Redis while the dev
profile targets Redis 2.8. Please note that starting with Redis 2.6 the output of INFO
is splitted into sections and, to accomodate this change, Predis returns nested named arrays when using the 2.6
profile.
Connection parameters and client options
There are some changes for connection parameters.
connection_async
is nowasync_connect
connection_timeout
is nowtimeout
connection_persistent
is nowpersistent
throw_errors
has been removed, replaced by the newexceptions
client option.
Please note that using the old parameter names with this new version does not raise any notice.
As an example, the following client configuration for Predis v0.7.x:
$parameters = "tcp://127.0.0.1?connection_async=1&connection_timeout=5&connection_persistent=1&throw_errors=1";
$client = new Predis\Client($parameters);
starting with Predis v0.8.0 must be changed into:
$parameters = "tcp://127.0.0.1?async_connect=1&timeout=5&persistent=1"
$client = new Predis\Client($parameters, array('exceptions' => true));
Additionally, the second parameter of the constructor of Predis\Client
does not accept strings or instances of Predis\Profile\ServerProfileInterface
like in the past but the server profile must be set by using the profile
client option explicitly:
$client = new Predis\Client('tcp://127.0.0.1', '2.4'); // Wrong
$client = new Predis\Client('tcp://127.0.0.1', array('profile' => '2.4')); // OK
Redis Cluster
While redis-cluster will not be available until Redis 3.0, Predis already ships with a first working implementation of the logic needed to use this amazing new feature. Configuring the client is simply a matter of passing the list of nodes in the same exact order as they are specified when using redis-trib
and setting the cluster
client option to redis
:
$nodes = array('tcp://10.0.0.1', 'tcp://10.0.0.2', 'tcp://10.0.0.3');
$client = new Predis\Client($nodes, array('cluster' => 'redis'));
Obviously you can rest assured that the good old way of creating a cluster of Redis nodes simply by relying on client-side sharding is still in place and is the default behavior of the client.
Server-side scripting with Lua
Predis supported Redis scripting since v0.7.0 but our high-level abstraction built on top of EVAL
and EVALSHA
(we call it a scripted command) has been improved to save bandwidth by using the latter by default and falling back transparently to the former when required (that is, when Redis replies to EVALSHA
with a -NOSCRIPT
error).
Going asynchronous with Predis\Async
Crazy? Maybe, but at least now you can thanks to Predis\Async. This separate project shares the same style and feel of Predis by reusing some of its core classes and is built on top of React to provide a fully-asynchronous implementation of a Redis client. The library is considered experimental and subject to changes in its API, but it already works and can cooperate seamlessy with any other library that makes use of the core event loop abstraction provided by React/EventLoop.
Future development
While this new major release admittedly do not add much features to the plate aside from early support for redis-cluster and a separate project for a fully-asynchronous client, the internals of Predis have been extensively reworked to make the library and its core parts even more easy to extend and reuse, but also with some optimizations put in place. We are at a point in which further changes to the internal architecture of Predis should not be needed for a while, or at least not until we decide to drop compatibility with PHP 5.3 and rewrite stuff to make use of new features introduced in PHP 5.4, which means that we can proceed with experimenting a few ideas such as having core parts of the library implemented in C as an optional PHP extension. Right now you can already use phpiredis to speed thins up, but we can definitely do better that that.
In a more immediate future, aside from addressing eventual bugs the next patch releases in the v0.8.x series will also see the addition of some missing features such as an abstration to deal with redis-sentinel.