Move doc metadata from COMMAND to COMMAND DOCS #10056
Conversation
Syntax: COMMAND DETAILS [<command name> ...] Background: Apparently old version of hiredis (and thus also redis-cli) can't support more than 7 levels of multi-bulk nesting. The solution is to move all the doc related metadata from COMMAND to a new COMMAND DETAILS sub-command. Besides that, the remaining new fields of COMMAND (hints, key-specs, and sub-commands), are placed in the outer array rather than a nested map. this was done mainly for consistency with the old format. Other changes: --- Reduce the amount of deferred replies from both COMMAND and COMMAND DETAILS, especially in the inner loops, since these create many small reply objects, which lead to many small write syscalls and many small TCP packets. To make this easier, when populating the command table, we count the history, args, and hints so we later know their size in advance. Additionally, the movablekeys flag was moved into the flags register. Update generate-commands-json.py to take the data from both command, it now executes redis-cli directly, instead of taking input from stdin. When a user specifically asks for a sub-command using COMMAND INFO <cmd>, or COMMAND DETAILS <cmd>, the response will contain the full command name, rather than just the sub-command name. i.e. `COMMAND INFO "config|get"` will return "config get" as name, rather than just "get". unlike asking for "config" (or asking for all commands), which will return a section about "get" in a nested block inside "config".
Co-authored-by: Viktor Söderqvist <[email protected]>
|
@redis/core-team please approve (see the top comment), and also state if you think the new command should be named COMMAND DOCS rather than COMMAND DETAILS (which resembles COMMAND INFO too much) |
oranagra
added
approval-needed
|
Hi,
|
I would assume COMMAND DOCS would give the full docs as on the documentation web page. Thus, I prefer DETAILS (or possibly something else... EXTRAINFO, MOREINFO, DOCINFO, MISC...?) |
How about
IIUC, this means the structure of the reply will be the same (in terms of levels) but the command will include all subcommands, whereas a subcommand will only list its parent command and itself (but no siblings). Is that what you mean? If so, think this makes sense. |
|
@yossigo i don't think what you described is what i meant. now here are the alternatives:
|
|
for the record, this was discussed in a core-team meeting and got a green light to merge. |
|
Why the pipe in " |
|
some context on the pipe char. so it looks like we're already "invested" in having the pipe char as a separator when a single string refers to a sub-command's full name. |
oranagra
changed the title
Co-authored-by: Viktor Söderqvist <[email protected]>
…9934) There are scenarios where it results in many small objects in the reply list, such as commands heavily using deferred array replies (`addReplyDeferredLen`). E.g. what COMMAND command and CLUSTER SLOTS used to do (see #10056, #7123), but also in case of a transaction or a pipeline of commands that use just one differed array reply. We used to have to run multiple loops along with multiple calls to `write()` to send data back to peer based on the current code, but by means of `writev()`, we can gather those scattered objects in reply list and include the static reply buffer as well, then send it by one system call, that ought to achieve higher performance. In the case of TLS, we simply check and concatenate buffers into one big buffer and send it away by one call to `connTLSWrite()`, if the amount of all buffers exceeds `NET_MAX_WRITES_PER_EVENT`, then invoke `connTLSWrite()` multiple times to avoid a huge massive of memory copies. Note that aside of reducing system calls, this change will also reduce the amount of small TCP packets sent.
Syntax:
COMMAND DOCS [<command name> ...]Background:
Apparently old version of hiredis (and thus also redis-cli) can't
support more than 7 levels of multi-bulk nesting.
The solution is to move all the doc related metadata from COMMAND to a
new COMMAND DOCS sub-command.
The new DOCS sub-command returns a map of commands (not an array like in COMMAND),
And the same goes for the
subcommandsfield inside it (also contains a map)Besides that, the remaining new fields of COMMAND (hints, key-specs, and
sub-commands), are placed in the outer array rather than a nested map.
this was done mainly for consistency with the old format.
Other changes:
Allow COMMAND INFO with no arguments, which returns all commands, so that we can some day deprecated
the plain COMMAND (no args)
Reduce the amount of deferred replies from both COMMAND and COMMAND
DOCS, especially in the inner loops, since these create many small
reply objects, which lead to many small write syscalls and many small
TCP packets.
To make this easier, when populating the command table, we count the
history, args, and hints so we later know their size in advance.
Additionally, the movablekeys flag was moved into the flags register.
Update generate-commands-json.py to take the data from both commands, it
now executes redis-cli directly, instead of taking input from stdin.
Sub-commands in both COMMAND (and COMMAND INFO), and also COMMAND DOCS, show their full name. i.e. CONFIG
GET will be shown as
config|getrather than justget.This will be visible both when asking for
COMMAND INFO configandCOMMAND INFO config|get, but is especiallyimportant for the later.
i.e. imagine someone doing
COMMAND INFO slowlog|get config|getnot being able to distinguish between the two items inthe array response.