The PR introduce a new proc macro for command registrations.

[MeirShpilraien]

The PR introduce a new proc macro for command registrations with the new command registration API that was introduced on Redis 7.

The new proc macro are called command, The following command will register the test_command function as a Redis command called foo:

#[command(
    {
        name: "test",
        flags: [ReadOnly],
        arity: -2,
        key_spec: [
            {
                notes: "test command that define all the arguments at even possition as keys",
                flags: [ReadOnly, Access],
                begin_search: Keyword({ keyword : "foo", startfrom : 1 }),
                find_keys: Range({ last_key :- 1, steps : 2, limit : 0 }),
            }
        ]
    }
)]
fn test_command(_ctx: &Context, _args: Vec<RedisString>) -> RedisResult {
    Ok(RedisValue::SimpleStringStatic("OK"))
}

The supported properties are:

• name - The command name,
• flags - An array of RedisCommandFlags.
• summary (optional) - Command summary
• complexity (optional) - Command compexity
• since (optional) - At which module version the command was first introduce
• tips (optional) - Command tips for proxy, for more information please refer to https://redis.io/topics/command-tips
• arity - Number of arguments, including the command name itself. A positive number specifies an exact number of arguments and a negative number specifies a minimum number of arguments.
• key_spec - A list of specs representing how to find the keys that the command might touch. the following options are available:
  • notes (optional) - Some note about the key spec.
  • flags - List of flags reprenting how the keys are accessed, the following options are available:
    • Readonly - Read-Only. Reads the value of the key, but doesn't necessarily return it.
    • ReadWrite - Read-Write. Modifies the data stored in the value of the key or its metadata.
    • Overwrite - Overwrite. Overwrites the data stored in the value of the key.
    • Remove - Deletes the key.
    • Access - Returns, copies or uses the user data from the value of the key.
    • Update - Updates data to the value, new value may depend on the old value.
    • Insert - Adds data to the value with no chance of modification or deletion of existing data.
    • Delete - Explicitly deletes some content from the value of the key.
    • NotKey - The key is not actually a key, but should be routed in cluster mode as if it was a key.
    • Incomplete - The keyspec might not point out all the keys it should cover.
    • VariableFlags - Some keys might have different flags depending on arguments.
  • begin_search - Represents how Redis should start looking for keys.There are 2 possible options:
    • Index - start looking for keys from a given position.
    • Keyword - Search for a specific keyward and start looking for keys from this keyword
  • FindKeys - After Redis finds the location from where it needs to start looking for keys, Redis will start finding keys base on the information in this struct. There are 2 possible options:
    • Range - An object of three elements last_key, steps, limit.
      • last_key - Index of the last key relative to the result of the begin search step. Can be negative, in which case it's not relative. -1 indicates the last argument, -2 one before the last and so on.
      • steps - How many arguments should we skip after finding a key, in order to find the next one.
      • limit - If lastkey is -1, we use limit to stop the search by a factor. 0 and 1 mean no limit. 2 means 1/2 of the remaining args, 3 means 1/3, and so on.
    • Keynum - An object of 3 elements keynumidx, firstkey, keystep.
      • keynumidx - Index of the argument containing the number of keys to come, relative to the result of the begin search step.
      • firstkey - Index of the fist key relative to the result of thebegin search step. (Usually it's just after keynumidx, inwhich case it should be set to keynumidx + 1.) * keystep - How many arguments should we skip after finding a key, in order to find the next one?

Notice, by default Redis does not validate the command spec. User should validate the command keys on the module command code. The command spec is used for validation on cluster so Redis can raise a cross slot error when needed.

Ideas for future extensions:

• The proc macro can analyze the function inputs and generate a code for parsing the command arguments so that the command function will not have to deal with it.

[iddm]

Excellent work! I was doing almost the same behind the scenes, and as a user, I would personally love this approach compared to the long-long redis_macro. The more things we can split out, the better, in my opinion, just as it is done with other projects, for example, social network bots. I hope we continue adding more procedural macros in the future to make it much easier for the user to create modules, at the same time lowering the boundary for creating it by greatly simplifying the code and making it much more concise.

I suggest a few changes though, which, I think, are reasonable.

[iddm]

It would be too easy to mess up with the range values. I suggest removing the comments and having strict names for these fields instead of the unnamed ones within a tuple. As another alternative, we can provide transparent types, but this would be overcomplicating the situation, compared to just having named fields.

[iddm]

Can we use the named fields here instead of the comment, please?