|
1 | 1 | export const REQUEST_POLICIES_WITH_DEFAULTS = {
|
| 2 | + /** |
| 3 | + * The client should execute the command on all nodes - masters and replicas alike. |
| 4 | + * This tip is in-use by commands that don't accept key name arguments. |
| 5 | + * The command operates atomically per shard. |
| 6 | + */ |
2 | 7 | ALL_NODES: "all_nodes",
|
| 8 | + /** |
| 9 | + * The client should execute the command on all master shards (e.g., the DBSIZE command). |
| 10 | + * This tip is in-use by commands that don't accept key name arguments. |
| 11 | + * The command operates atomically per shard. |
| 12 | + */ |
3 | 13 | ALL_SHARDS: "all_shards",
|
| 14 | + /** |
| 15 | + * The client should execute the command on several shards. |
| 16 | + * The client should split the inputs according to the hash slots of its input key name arguments. |
| 17 | + * For example, the command DEL {foo} {foo}1 bar should be split to DEL {foo} {foo}1 and DEL bar. |
| 18 | + * If the keys are hashed to more than a single slot, |
| 19 | + * the command must be split even if all the slots are managed by the same shard. |
| 20 | + * Examples for such commands include MSET, MGET and DEL. |
| 21 | + * However, note that SUNIONSTORE isn't considered as multi_shard because all of its keys must belong to the same hash slot. |
| 22 | + */ |
4 | 23 | MULTI_SHARD: "multi_shard",
|
| 24 | + /** |
| 25 | + * Indicates a non-trivial form of the client's request policy, such as the SCAN command. |
| 26 | + */ |
5 | 27 | SPECIAL: "special",
|
| 28 | + /** |
| 29 | + * The default behavior a client should implement for commands without the request_policy tip is as follows: |
| 30 | + * |
| 31 | + * 1. The command doesn't accept key name arguments: |
| 32 | + * the client can execute the command on an arbitrary shard. |
| 33 | + */ |
6 | 34 | DEFAULT_KEYLESS: "default-keyless",
|
| 35 | + /** |
| 36 | + * The default behavior a client should implement for commands without the request_policy tip is as follows: |
| 37 | + * |
| 38 | + * 2. For commands that accept one or more key name arguments: |
| 39 | + * the client should route the command to a single shard, |
| 40 | + * as determined by the hash slot of the input keys. |
| 41 | + */ |
7 | 42 | DEFAULT_KEYED: "default-keyed"
|
8 | 43 | } as const;
|
9 | 44 |
|
10 | 45 | export type RequestPolicyWithDefaults = typeof REQUEST_POLICIES_WITH_DEFAULTS[keyof typeof REQUEST_POLICIES_WITH_DEFAULTS];
|
11 | 46 |
|
12 | 47 | export const RESPONSE_POLICIES_WITH_DEFAULTS = {
|
| 48 | + /** |
| 49 | + * The client should return success if at least one shard didn't reply with an error. |
| 50 | + * The client should reply with the first non-error reply it obtains. |
| 51 | + * If all shards return an error, the client can reply with any one of these. |
| 52 | + * Example: SCRIPT KILL command that's sent to all shards. |
| 53 | + */ |
13 | 54 | ONE_SUCCEEDED: "one_succeeded",
|
| 55 | + /** |
| 56 | + * The client should return successfully only if there are no error replies. |
| 57 | + * Even a single error reply should disqualify the aggregate and be returned. |
| 58 | + * Otherwise, the client should return one of the non-error replies. |
| 59 | + * Examples: CONFIG SET, SCRIPT FLUSH and SCRIPT LOAD commands. |
| 60 | + */ |
14 | 61 | ALL_SUCCEEDED: "all_succeeded",
|
| 62 | + /** |
| 63 | + * The client should return the result of a logical AND operation on all replies. |
| 64 | + * Only applies to integer replies, usually from commands that return either 0 or 1. |
| 65 | + * Example: SCRIPT EXISTS command returns 1 only when all shards report that a given script SHA1 sum is in their cache. |
| 66 | + */ |
15 | 67 | AGG_LOGICAL_AND: "agg_logical_and",
|
| 68 | + /** |
| 69 | + * The client should return the result of a logical OR operation on all replies. |
| 70 | + * Only applies to integer replies, usually from commands that return either 0 or 1. |
| 71 | + */ |
16 | 72 | AGG_LOGICAL_OR: "agg_logical_or",
|
| 73 | + /** |
| 74 | + * The client should return the minimal value from the replies. |
| 75 | + * Only applies to numerical replies. |
| 76 | + * Example: WAIT command should return the minimal number of synchronized replicas from all shards. |
| 77 | + */ |
17 | 78 | AGG_MIN: "agg_min",
|
| 79 | + /** |
| 80 | + * The client should return the maximal value from the replies. |
| 81 | + * Only applies to numerical replies. |
| 82 | + */ |
18 | 83 | AGG_MAX: "agg_max",
|
| 84 | + /** |
| 85 | + * The client should return the sum of replies. |
| 86 | + * Only applies to numerical replies. |
| 87 | + * Example: DBSIZE command. |
| 88 | + */ |
19 | 89 | AGG_SUM: "agg_sum",
|
| 90 | + /** |
| 91 | + * Indicates a non-trivial form of reply policy. |
| 92 | + * Example: INFO command with complex aggregation logic. |
| 93 | + */ |
20 | 94 | SPECIAL: "special",
|
| 95 | + /** |
| 96 | + * The default behavior for commands without a response_policy tip that don't accept key name arguments: |
| 97 | + * the client can aggregate all replies within a single nested data structure. |
| 98 | + * Example: KEYS command replies should be packed in a single array in no particular order. |
| 99 | + */ |
21 | 100 | DEFAULT_KEYLESS: "default-keyless",
|
| 101 | + /** |
| 102 | + * The default behavior for commands without a response_policy tip that accept one or more key name arguments: |
| 103 | + * the client needs to retain the same order of replies as the input key names. |
| 104 | + * Example: MGET's aggregated reply should maintain key order. |
| 105 | + */ |
22 | 106 | DEFAULT_KEYED: "default-keyed"
|
23 | 107 | } as const;
|
24 | 108 |
|
|
0 commit comments