adjust the format string passed to redis_cmd_format_static() to
properly handle long int, in order to prevent integer overflows
resulting in negative expire times passed to redis.
This relates to a previous hotfix for issue #379 where phpredis
would time out if you sent an array of empty values. The reason
it was timing out is that the argument count being sent wasn't
reflecting any skipped items in the array (meaning redis was
waiting for the rest of the command).
I realized that the previous fix would still fail if you were to
send some valid values, with invalid (null, empty string, etc)
ones mixed in.
Presently, we're just skipping invalid items in the array but there
might be a case to issue a php_error_docref type warning when we
encounter them, so the user can know that it happened.
In addition, HMGET now uses a smart_str to build the command, which
means the time it takes to build the key will scale in a linear fashion
Use the lengths for our optional parameters, as NULL will
come through as a non null zval pointer with a zero length
Properly return the length from the redis_cmd_sstr_init function
This commit changes how we build the Redis protocol string for
ZUNIONSTORE and ZINTERSTORE such that we avoid reallocating
memory for the command buffer for each new key or weight
I accidentally pulled this when getting some of the pull requests
integrated (git flow style) for this release. I like the idea
for sure, but I think it needs more detailed documentation and
further testing.
At the very least, I need to understand it :)
This commit changes the way we construct the MGET command
such that we avoid allocating and reallocating the command
string pointer for every new key that is added.
This means that MGET performance scales in a linear way rather
than exponentially.
When using the TTL command, Redis >= 2.8 will return -1 for a key
with no TTL and -2 for a key that doesn't exist. This fixes the
unit tests so they don't expect this in versions < 2.8.
When calling php library methods to convert doubles to strings
we were only keeping 8 digits after the decimal point. For
double precision numbers, 15 are stable.
Redis uses the C library function strtod() to do the conversion,
which appears to use the first 16 digits for aproximation:
http://www.exploringbinary.com/how-strtod-works-and-sometimes-doesnt/
This hotfix increases the signifigant digits to 16, which I think
is the correct number to pick here.
Addresses issue #371
