Skip to content

Commit ac3291f

Browse files
Merge pull request #1797 from redis/DOC-5419-commands-section
DOC-5419 added commands section
2 parents 85f82c3 + 63c57cf commit ac3291f

File tree

25 files changed

+110
-39
lines changed

25 files changed

+110
-39
lines changed

content/commands/command.md

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -101,7 +101,7 @@ Command flags are an array. It can contain the following simple strings (status
101101
* **no_auth:** executing the command doesn't require authentication.
102102
* **no_async_loading:** the command is denied during asynchronous loading (that is when a replica uses disk-less `SWAPDB SYNC`, and allows access to the old dataset).
103103
* **no_mandatory_keys:** the command may accept key name arguments, but these aren't mandatory.
104-
* **no_multi:** the command isn't allowed inside the context of a [transaction]({{< relref "/develop/reference/transactions" >}}).
104+
* **no_multi:** the command isn't allowed inside the context of a [transaction]({{< relref "develop/using-commands/transactions" >}}).
105105
* **noscript:** the command can't be called from [scripts]({{< relref "/develop/programmability/eval-intro" >}}) or [functions]({{< relref "/develop/programmability/functions-intro" >}}).
106106
* **pubsub:** the command is related to [Redis Pub/Sub]({{< relref "/develop/pubsub" >}}).
107107
* **random**: the command returns random results, which is a concern with verbatim script replication.

content/commands/scan.md

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -286,7 +286,7 @@ Also note that this behavior is specific of [`SSCAN`]({{< relref "/commands/ssca
286286

287287
## Further reading
288288

289-
For more information about managing keys, please refer to the [The Redis Keyspace]({{< relref "/develop/keyspace" >}}) tutorial.
289+
For more information about managing keys, please refer to the [The Redis Keyspace]({{< relref "/develop/using-commands/keyspace" >}}) tutorial.
290290

291291
## Additional examples
292292

content/develop/ai/search-and-query/best-practices/index-mgmt-best-practices.md

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -150,7 +150,7 @@ Monitoring and troubleshooting aliases:
150150
## Index maintenance
151151
152152
- If schema changes are required, create a new index with the updated schema and reassign the alias once the index is ready.
153-
- Use [Redis key expiration]({{< relref "/develop/keyspace#key-expiration" >}}) to automatically remove outdated records and keep indexes lean.
153+
- Use [Redis key expiration]({{< relref "/develop/using-commands/keyspace#key-expiration" >}}) to automatically remove outdated records and keep indexes lean.
154154
155155
### FT.ALTER vs. aliasing
156156

content/develop/clients/dotnet/condexec.md

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -17,7 +17,7 @@ weight: 60
1717

1818
Most Redis client libraries use transactions with the
1919
[`WATCH`]({{< relref "/commands/watch" >}}) command as the main way to prevent
20-
two clients writing to the same key at once (see [Transactions]({{< relref "/develop/reference/transactions" >}}) for more information). Unfortunately, this approach is
20+
two clients writing to the same key at once (see [Transactions]({{< relref "develop/using-commands/transactions" >}}) for more information). Unfortunately, this approach is
2121
difficult to use explicitly in `NRedisStack`. Its
2222
[multiplexing]({{< relref "/develop/clients/pools-and-muxing" >}}) system
2323
is highly efficient and convenient but can also cause bad interactions

content/develop/clients/dotnet/transpipe.md

Lines changed: 3 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -21,11 +21,11 @@ There are two types of batch that you can use:
2121
- **Pipelines** avoid network and processing overhead by sending several commands
2222
to the server together in a single communication. The server then sends back
2323
a single communication with all the responses. See the
24-
[Pipelining]({{< relref "/develop/reference/pipelining" >}}) page for more
24+
[Pipelining]({{< relref "/develop/using-commands/pipelining" >}}) page for more
2525
information.
2626
- **Transactions** guarantee that all the included commands will execute
2727
to completion without being interrupted by commands from other clients.
28-
See the [Transactions]({{< relref "/develop/reference/transactions" >}})
28+
See the [Transactions]({{< relref "develop/using-commands/transactions" >}})
2929
page for more information.
3030

3131
## Execute a pipeline
@@ -57,7 +57,7 @@ to different keys. The basic idea is to watch for changes to any
5757
keys that you use in a transaction while you are are processing the
5858
updates. If the watched keys do change, you must restart the updates
5959
with the latest data from the keys. See
60-
[Transactions]({{< relref "/develop/reference/transactions" >}})
60+
[Transactions]({{< relref "develop/using-commands/transactions" >}})
6161
for more information about optimistic locking.
6262

6363
The approach to optimistic locking that other clients use

content/develop/clients/go/transpipe.md

Lines changed: 3 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -21,11 +21,11 @@ There are two types of batch that you can use:
2121
- **Pipelines** avoid network and processing overhead by sending several commands
2222
to the server together in a single communication. The server then sends back
2323
a single communication with all the responses. See the
24-
[Pipelining]({{< relref "/develop/reference/pipelining" >}}) page for more
24+
[Pipelining]({{< relref "/develop/using-commands/pipelining" >}}) page for more
2525
information.
2626
- **Transactions** guarantee that all the included commands will execute
2727
to completion without being interrupted by commands from other clients.
28-
See the [Transactions]({{< relref "/develop/reference/transactions" >}})
28+
See the [Transactions]({{< relref "develop/using-commands/transactions" >}})
2929
page for more information.
3030

3131
## Execute a pipeline
@@ -77,7 +77,7 @@ to different keys. The basic idea is to watch for changes to any
7777
keys that you use in a transaction while you are are processing the
7878
updates. If the watched keys do change, you must restart the updates
7979
with the latest data from the keys. See
80-
[Transactions]({{< relref "/develop/reference/transactions" >}})
80+
[Transactions]({{< relref "develop/using-commands/transactions" >}})
8181
for more information about optimistic locking.
8282

8383
The code below reads a string

content/develop/clients/hiredis/transpipe.md

Lines changed: 3 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -21,11 +21,11 @@ There are two types of batch that you can use:
2121
- **Pipelines** avoid network and processing overhead by sending several commands
2222
to the server together in a single communication. The server then sends back
2323
a single communication with all the responses. See the
24-
[Pipelining]({{< relref "/develop/reference/pipelining" >}}) page for more
24+
[Pipelining]({{< relref "/develop/using-commands/pipelining" >}}) page for more
2525
information.
2626
- **Transactions** guarantee that all the included commands will execute
2727
to completion without being interrupted by commands from other clients.
28-
See the [Transactions]({{< relref "/develop/reference/transactions" >}})
28+
See the [Transactions]({{< relref "develop/using-commands/transactions" >}})
2929
page for more information.
3030

3131
## Execute a pipeline
@@ -109,5 +109,5 @@ when you have finished processing it, as in the example above.
109109
you can implement them yourself using the [`MULTI`]({{< relref "/commands/multi" >}}),
110110
[`EXEC`]({{< relref "/commands/exec" >}}), and [`WATCH`]({{< relref "/commands/watch" >}})
111111
commands as you would from [`redis-cli`]({{< relref "/develop/tools/cli" >}}).
112-
See [Transactions]({{< relref "/develop/reference/transactions" >}})
112+
See [Transactions]({{< relref "develop/using-commands/transactions" >}})
113113
for more information.

content/develop/clients/jedis/transpipe.md

Lines changed: 3 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -21,11 +21,11 @@ There are two types of batch that you can use:
2121
- **Pipelines** avoid network and processing overhead by sending several commands
2222
to the server together in a single communication. The server then sends back
2323
a single communication with all the responses. See the
24-
[Pipelining]({{< relref "/develop/reference/pipelining" >}}) page for more
24+
[Pipelining]({{< relref "/develop/using-commands/pipelining" >}}) page for more
2525
information.
2626
- **Transactions** guarantee that all the included commands will execute
2727
to completion without being interrupted by commands from other clients.
28-
See the [Transactions]({{< relref "/develop/reference/transactions" >}})
28+
See the [Transactions]({{< relref "develop/using-commands/transactions" >}})
2929
page for more information.
3030

3131
## Execute a pipeline
@@ -68,7 +68,7 @@ to different keys. The basic idea is to watch for changes to any
6868
keys that you use in a transaction while you are are processing the
6969
updates. If the watched keys do change, you must restart the updates
7070
with the latest data from the keys. See
71-
[Transactions]({{< relref "/develop/reference/transactions" >}})
71+
[Transactions]({{< relref "develop/using-commands/transactions" >}})
7272
for more information about optimistic locking.
7373

7474
The code below reads a string

content/develop/clients/nodejs/transpipe.md

Lines changed: 3 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -21,11 +21,11 @@ There are two types of batch that you can use:
2121
- **Pipelines** avoid network and processing overhead by sending several commands
2222
to the server together in a single communication. The server then sends back
2323
a single communication with all the responses. See the
24-
[Pipelining]({{< relref "/develop/reference/pipelining" >}}) page for more
24+
[Pipelining]({{< relref "/develop/using-commands/pipelining" >}}) page for more
2525
information.
2626
- **Transactions** guarantee that all the included commands will execute
2727
to completion without being interrupted by commands from other clients.
28-
See the [Transactions]({{< relref "/develop/reference/transactions" >}})
28+
See the [Transactions]({{< relref "develop/using-commands/transactions" >}})
2929
page for more information.
3030

3131
## Execute a pipeline
@@ -112,7 +112,7 @@ to different keys. The basic idea is to watch for changes to any
112112
keys that you use in a transaction while you are are processing the
113113
updates. If the watched keys do change, you must restart the updates
114114
with the latest data from the keys. See
115-
[Transactions]({{< relref "/develop/reference/transactions" >}})
115+
[Transactions]({{< relref "develop/using-commands/transactions" >}})
116116
for more information about optimistic locking.
117117

118118
The code below reads a string

content/develop/clients/pools-and-muxing.md

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -71,7 +71,7 @@ used to identify where to send the response data from your commands.
7171

7272
Note that it is not a problem if the multiplexer receives several commands close
7373
together in time. When this happens, the multiplexer can often combine the commands into a
74-
[pipeline]({{< relref "/develop/reference/pipelining" >}}), which
74+
[pipeline]({{< relref "/develop/using-commands/pipelining" >}}), which
7575
improves efficiency.
7676

7777
Multiplexing offers high efficiency but works transparently without requiring

0 commit comments

Comments
 (0)