Unfortunately `VEMB` has a unique `RESP2` reply as far as I can tell,
where it sends the embedding mode (int8, bin, fp32) as a simple string.
This would cause any of PhpRedis' generic reply handlers to turn that
into `true` which isn't useful. For that reason we need a custom reply
handler.
Additionally slightly rework `VINFO` to short circuit and return failure
if we read anything other than a bulk string or an integer reply type.
Otherwise we may get out of sync on the socket.
See #2543
All of these commands have the same form `<cmd> key`. `VINFO` is a bit
of an outlier however that uses simple strings as opposed to bulk
strings for the key names, meaning we had to create a custom handler.
See #2543
Right now we can't implement `HELLO` command to switch protocol
because we don't support new reply types that come with RESP3.
But we can use `HELLO` reply to expose some server information.
We also need to update the `RedisCluster` logic to handle very large
curosr values, in addition to handling them for the `Redis` and
`RedisArray` classes.
See #2454, #2458
Technically Redis may return any unsigned 64 bit integer as a scan
cursor. This presents a problem for PHP in that PHP's integers are
signed. Because of that if a scan cursor is > 2^63 it will overflow and
fail to work properly.
This commit updates our SCAN family of commands to deliver cursors in
their string form.
```php
public function scan(null|int|string $iterator, ...);
```
On initial entry into our SCAN family we convert either a NULL or empty
string cursor to zero, and send the initial scan command.
As Redis replies with cursors we either represent them as a long (if
they are <= ZEND_ULONG_MAX) and as a string if greater. This should
mean the fix is minimally breaking as the following code will still
work:
```php
$it = NULL;
do {
print_r($redis->scan($it));
} while ($it !== 0);
```
The `$it !== 0` still works because the zero cursor will be represented
as an integer. Only absurdly large (> 2^63) values are represented as a
string.
Fixes#2454
* fix bug: the pipeline mode socket return an unexpected result after reconnecting
* fix typos: pipeline is right
---------
Co-authored-by: marcofu <marcofu@tencent.com>
* Use our `redis_cmd_append_sstr_key_*` and `redis_cmd_append_sstr_zval`
wrappers, which handle key prefixing and serialization transparently.
* Rework ZADD so it can handle the bulk double response from the `INCR`
options.
* Use our common command handler logic for SELECT.
* Shift updating `redis_sock->dbNumber` from the command itself to the
reply handler, so we aren't erroneously pointing to a non-existent
database before the command succeeds.
* Implement `ZDIFF`, `ZINTER`, `ZUNION`, `ZMSCORE`, and
`ZRANDMEMBER` for `RedisCluster`.
* Refactor `ZUNIONSTORE` command and switch to using our centralized
zset option parsing handler.
See #1894
* Create inline wrappers of the low-level php_stream_* functions that
also keep track of the number of bytes written/read.
* Change the logic to aggregate network traffic until the user
explicitly "resets" it. I think this will be a more common use-case
(running many commands and then seeing overall network IO).
See #2106
- Finish adding docblocks with examples for all of the stream commands.
- Fix XAUTOCLAIM response handler (the reply has a slightly different
structure to XCLAIM.
* Add ZRANGESTORE command.
* Add Redis 6.2's `REV`, `BYLEX`, and `BYSCORE` to ZRANGE options.
* Refactor several ZRANGE family commands into a single reply and
options handler, using PHP's new argument parsing macros.
* Extend our tests to use the new ZRANGE options.
See #1894
Redis 7.0.0 allows for getting and setting multiple config values as an
atomic operation. In order to support this while maintaining backward
compatibility, the CONFIG command is reworked to also accept an array of
values or keys and values.
See: #2068
Implement the new Redis 7.0.0 commands to pop multiple elements from one
or more lists/zsets.
Additionally, remove INTERNAL_FUNCTION_PARAMETERS from the
redis_sock_read_multibulk_reply_zval helper function as it wasn't
actually being used.
