JSON.MGET

Returns the values at a path from one or more keys

Browse all commands · Upstream source documentation

Reference field	Value
Canonical name	JSON.MGET
Catalog group	JSON commands
Upstream since	1.0.0 — upstream Redis/module version, not an ffkv release
Pinned catalog	Redis 8.10.0

Syntax

JSON.MGET key [key ...] path

ffkv behavior and limits

Documents cap at 4 MiB compact JSON, 262,144 nodes and depth 128. Paths cap at 16 KiB and matching at 65,536 results, with additional expression/projection work budgets. JSON trees stay RAM-resident in hybrid mode.

Source: README.md:357–358, 375–377; tests/bdd/features/json.feature.

All requests share the 8 MiB framing/1,024-argument ingress limit; normal RESP replies have 64 MiB wire/logical budgets with bounded nesting/value counts. Management and Lua origins impose smaller budgets. These are not a process RSS cap. Catalog inclusion is not exhaustive option or wire-format parity. See limits and compatibility.

Metadata availability

This command is in the canonical catalog but has no matching entry in the pinned src/command_metadata.json. Argument flags, complexity and key specifications are not invented. Use the syntax, upstream source documentation and actual scenario evidence below.

BDD coverage and source examples

These are source observations, not a test run performed by this documentation build. A tag identifies scenario intent; an extracted vector identifies a command invocation, which may intentionally produce an error. Scenarios may require setup, multiple connections, persistence, cluster nodes or native-module fixtures.

• Multi-document assignment is atomic and multi-get preserves missing keys — tests/bdd/features/json.feature:312; command tag and invocation observed.
• Repeated read selectors preserve their sequence while mutations use unique targets — tests/bdd/features/json.feature:373; command tag and invocation observed.

Extracted command vectors

The following JSON arrays are the test harness’s argument vectors, not shell commands. Numeric arguments are converted by the harness; objects of the form {"base64":"…"} represent decoded binary bytes, not a literal JSON command argument. Preserve scenario setup and connection ordering. See the CLI guide for shell quoting and binary stdin. No reply is invented or inferred.

Multi-document assignment is atomic and multi-get preserves missing keys — tests/bdd/features/json.feature:335 (I execute:)

[
  "JSON.MGET",
  "a",
  "b",
  "$.v"
]

Next source assertion: the reply equals:

["[1]","[2]"]

Repeated read selectors preserve their sequence while mutations use unique targets — tests/bdd/features/json.feature:387 (I execute:)

[
  "JSON.MGET",
  "j",
  "missing",
  "j",
  "$[1,0,1]"
]

Next source assertion: the reply equals:

["[20,10,20]",null,"[20,10,20]"]

Multi-document assignment is atomic and multi-get preserves missing keys — tests/bdd/features/json.feature:322 (I execute:)

[
  "JSON.MGET",
  "b",
  "absent",
  "a",
  "$.v"
]

Next source assertion: the reply equals:

["[2]",null,"[1]"]