tarantool-php
tarantool-php copied to clipboard
Consider moving tarantool.* ini settings to the instance level
Is there a reason to put settings like timeout, persistence, etc in php.ini
? Usually, such kind of settings are made to be configurable on an instance level, instead of globally. See some examples:
http://php.net/manual/en/mongodb-driver-manager.construct.php https://github.com/phpredis/phpredis#example-1 http://php.net/manual/en/function.pg-connect.php
So, currently you can't have two Tarantool instances with different timeout settings, or one with a persistent connection while the other with a regular one. Also, putting those settings in php.ini decreases scripts portability, as the same script can behave differently depending on php.ini settings.
You have ability to modify this settings using ini_set
, so it's no difference
@bigbes Do you propose to overwrite a global setting every time one need a custom one? Something like this? :
ini_set('tarantool.timeout', 5);
$t1 = new Tarantool();
ini_set('tarantool.timeout', 15);
$t2 = new Tarantool();
ini_set('tarantool.request_timeout', 5);
$t1->ping();
$t1->call(...);
ini_set('tarantool.request_timeout', 15);
$t2->ping();
$t2->call(...);
Or create a wrapper to modify and restore settings after a call:
function call_with_custom_timeout($tarantool, $args, $timeout)
{
$originalTimeout = ini_get('tarantool.request_timeout');
ini_set('tarantool.request_timeout', $timeout);
$tarantool->call($args);
ini_set('tarantool.request_timeout', $originalTimeout);
}
$t1 = new Tarantool();
$t2 = new Tarantool();
call_with_custom_timeout($t1, 'foo', 5);
call_with_custom_timeout($t2, 'bar', 15);
Both these options don't look right to me.
Discussed. When new API would be presented - it would be OK to implement this
NB: Don't forget to add call_16
option to choose default call()
behaviour. See PR #167 for the related discussion.
I like the idea suggested by @rybakit about using a separate static method (like Client::fromOptions()
) to construct a client from an associative array of options. The discussion is in PR #167.