* Add complete CI
* Fix CI
* Fix spelling
* Fix indentation
* Fix CI
* Fix CI
* Revert disabling unit tests
* Add coverage driver to CI
* Start coverage debugging
* Fix debugging
ignored, and an empty message aborts the commit.
* Stop debugging
* Move TODO-s from source to GitHub issues
* Ignore too long lines in certain files
* Revert requiring php-parallel-lint/php-parallel-lint
* formatting
* try shorter formatting
* formatting
* fix syntax
* try two paths?
* Update .editorconfig
Co-authored-by: Viktor Szépe <viktor@szepe.net>
* indentation
* make it a group
Co-authored-by: Till Krüss <tillkruss@users.noreply.github.com>
The username is now correctly retrieved from the userinfo fragment of
the URI when using the "redis" scheme and a "username:password" pair is
present. Values retrieved from the userinfo fragment always override the
ones specified in `username` and `password` if those fields are present
in the query string.
Having NULL values or zero-length strings for connection parameters does
not make much sense and actually it proved to be an issue with certain
parameters like "password" where an empty string would trigger an AUTH
command with an empty password (and obviously Redis was not happy with
that). The main offenders were a few libraries and frameworks that kept
passing empty values for parameters such as "database" and "password"
even when users left them unconfigured. This fix should make things more
robust and avoid such occurrences in the future.
Related to PR #436 (rejected).
Instead of using "unix://" you should just use "unix:":
$old = 'unix:///path/to/redis.sock';
$new = 'unix:/path/to/redis.sock';
The old format should be considered obsolete and will not be supported
starting from the next major release of Predis.
Meh
Falling back to a default timeout values should be done by the connection class
as it is an implementation detail that may vary depending on the backend.
Simply overriding one method of the standard connection factory class,
used internally by Predis, allows developers to use their own custom
connection parameters classes through the whole library.
For example, in order to support Heroku-style URIs one can do:
class HerokuParameters extends Predis\Connection\Parameters
{
protected function filter(array $parameters)
{
if (
isset($parameters['scheme']) &&
$parameters['scheme'] === 'redis'
) {
$parameters['scheme'] = 'tcp';
}
if (isset($parameters['pass'])) {
$parameters['password'] = $parameters['pass'];
}
unset($parameters['user'], $parameters['pass']);
return $parameters;
}
}
class ConnectionFactory extends Predis\Connection\Factory
{
protected function createParameters($parameters)
{
return HerokuParameters::create($parameters);
}
}
$client = new Predis\Client($_ENV['REDISCLOUD_URL'], [
'connections' => new ConnectionFactory()
]);
This idea comes in response to #196, but since we do not want to bake
support for SaaS-specific URIs in Predis this is the best compromise
we can offer leave developers free to implement their own logic for
handling these kind of URIs with the additional benefit of having it
available through the whole library (think of cluster or replication
where you have multiple nodes, thus multiple instances of connection
parameters to create).
Casting values supplied by users should be done by the consumer since
we cannot cover any possible use case anyway. It is still possible to
subclass Predis\Connection\Parameters and override the filter() method
to convert certain values if deemed necessary.
Till Krüss
Viktor Szépe
John Paul E. Balandan, CPA
Daniele Alessandri
Thibaud BARDIN