This is actually a temporary solution since we should be using a dedicated
pipeline executor to handle the master/slave replication connection.
Ideally we should stick with a slave if no write operations are present in
the buffer, but forcing a switch to the master connection is the easiest
solution for now and users can still create a new client instance from one
of the slaves when they are sure that their pipelines contain read-only
operations.
This can be useful to set up the profile with additional commands,
e.g. when injecting new "virtual" commands based upon the EVAL and
the Predis\Commands\ScriptedCommand class.
Some of these commands do not actually pose any threat, but their replies can
be misleading since users do not know on which server they are connected to.
We prefer to make things explicit so users can get a new client object out of
a specific connection in the replication pool to issue these commands.
Previously it was possible to create a new instance of Predis\Client using
the alias of a single connection in a cluster of connections. Now we added
the ability to do this also when using master/slave replication.
Since Pearhub is currently broken (unfortunately the project does not seem to
be actively mantained anymore) but we still want to have PEAR packages for our
library, we need to automate the creation of a package.xml definition file to
build the actual packages that will be uploaded on a self-hosted PEAR channel.
Onion, while still in its alpha stage right now, works perfectly fine for our
needs and its own package.ini file looks simple enough to edit and maintain.
See http://c9s.github.com/Onion for more details about Onion and thank @c9s
for making it available.
As suggested by @Seldaek in ISSUE #21, it would be desiderable to have the
ability to mark certain scripts for EVAL (and EVALSHA) as read-only to avoid
switching to the master server when this is not really needed.
When marking a script as read-only, only its SHA1 hash is saved to use less
memory and to make this work transparently for both EVAL and EVALSHA.
When the "replication" option is specified and evaluates to true, the array of
connection parameters passed to the client constructor os be used to initialize
a new instance of Predis\Network\IConnectionReplication. This option can also
accept a callable object used as an initializer or the fully-qualified name of
a class.
We used a new kind of virtual connection that, just like with cluster, groups
multiple connection objects and handles the logic needed to switch among them
depending on the kind of operation performed by commands..
Our default implementation starts by picking up a random slave and switches to
the master as soon as a command performing a write operation against a key is
detected. The master server will then be used for all the subsequent requests
unless a manual switch to a different connection object is performed.
Redis transactions are always performed on the master server, which means that
the switch to master is done as soon as the client issues a WATCH, MULTI or
any other command related to transactions.
See also https://github.com/nrk/predis/issues/21 for more details.
TravisCI environmenti run Redis 2.2 but we need Redis 2.4 to run the
integration tests in the test suite. For now we have simply disabled
the `connected` group of tests using a custom phpunit.xml file, we will
see later if it is worth building Redis on the fly with a `before_script`
directive in .travis.yml or just wait for a a new version of Redis to
be deployed on their VM images.
The reason is pretty simple: redis-cluster will not be available in a stable
release of Redis anytime soon, so there is no reason to wait anymore to get
it supported in Predis v0.7.
Fix also a few bugs found while rewriting the test suite.
In order to be able to run integration tests, the test suite requires
a version of Redis >= 2.4.0.
The units have been splitted into several different groups using
PHPUnit @group annotation to allow developers to enable, disable
and combine certain types of tests. The available groups are:
- disconnected: can run without a Redis server online
- connected: active connection to a Redis server is required
- commands: test dedicated to a specific Redis command
- slow: performs operations that can slow down execution;
A list of the available groups can be obtained by running
phpunit --list-groups
Groups of tests can be disabled or enabled via the XML configuration
file or the standard command-line test runner. Please note that due
to a bug in PHPUnit, older versions ignore the --group option when
the group is excluded in the XML configuration file. Please refer to
http://github.com/sebastianbergmann/phpunit/issues/320 for details
Integration tests in the @connected group check if the command being
tested is defined in the selected server profile (see the value of
the TEST_SERVER_VERSION constant in phpunit.xml). If the command is
not defined in the target server profile, the integration test is
automatically marked as skipped.
We also provide an helper script in the bin directory that can be
used to automatically generate a file with the scheleton of a test
case for a Redis command by specifying the name of the class in the
Predis\Commands namespace. For example, to generate a test case for
SET (represented by the Predis\Commands\StringSet class):
./bin/generate-command-test.php --class=StringSet
The realm of a command is automatically inferred from the name of the
class, but it can be set using the --realm option.
This change is useless right now, but when Predis will support Redis cluster
we will need to have access the connection factory object since it will be
required by our future RedisCluster class.
When we will have PHP 5.4 going mainstream and Predis will drop support for
PHP 5.3, we will be able to rely in traits to semplify code and reuse more.
Daniele Alessandri