- 29 Mar, 2023 1 commit
-
-
Itamar Haber authored
This is an attempt to normalize/formalize command summaries. Main actions performed: * Starts with the continuation of the phrase "The XXXX command, when called, ..." for user commands. * Starts with "An internal command...", "A container command...", etc... when applicable. * Always uses periods. * Refrains from referring to other commands. If this is needed, backquotes should be used for command names. * Tries to be very clear about the data type when applicable. * Tries to mention additional effects, e.g. "The key is created if it doesn't exist" and "The set is deleted if the last member is removed." * Prefers being terse over verbose. * Tries to be consistent.
-
- 05 Apr, 2022 1 commit
-
-
Madelyn Olson authored
The command json documents should just include information about the "arguments" and the "outputs". I removed all of the 'functional wording' so it's clear.
-
- 29 Dec, 2021 1 commit
-
-
Itamar Haber authored
Add missing information about commands, mainly from reviewing redis-doc and removing the metadata from it (https://github.com/redis/redis-doc/pull/1722) * Reintroduces CLUSTER S****S (supported by Redis) but missing from the JSON / docs (related? #9675). Note that without that json file, the command won't work (breaking change) * Adds the `replicas` argument (exists in Redis) to `CLIENT KILL`. * Adds `history` entries to several commands based on redis-doc's man pages. * Adds `since` to applicable command arguments based on `history` (this basically makes some of `history` redundant - perhaps at a later stage). * Uses proper semantic versioning in all version references. * Also removes `geoencodeCommand` and `geodecodeCommand` header declarations per b96af595.
-
- 15 Dec, 2021 1 commit
-
-
guybe7 authored
Delete the hardcoded command table and replace it with an auto-generated table, based on a JSON file that describes the commands (each command must have a JSON file). These JSON files are the SSOT of everything there is to know about Redis commands, and it is reflected fully in COMMAND INFO. These JSON files are used to generate commands.c (using a python script), which is then committed to the repo and compiled. The purpose is: * Clients and proxies will be able to get much more info from redis, instead of relying on hard coded logic. * drop the dependency between Redis-user and the commands.json in redis-doc. * delete help.h and have redis-cli learn everything it needs to know just by issuing COMMAND (will be done in a separate PR) * redis.io should stop using commands.json and learn everything from Redis (ultimately one of the release artifacts should be a large JSON, containing all the information about all of the commands, ...
-