zarr_metadata.problems
zarr_metadata.problems ¶
The problems every reader in this package reports, and the error that carries them.
A reader returns problems as values: typed_json.check, definition.resolve
and the model readers each return a tuple of ValidationProblem. Each
problem has a loc (where it is), a kind (one of the ProblemKind
values, for code that handles problems by kind), a message, and the
input and ctx its message is made from. A constructor that cannot
return problems, such as a model's from_json, raises
MetadataValidationError with every problem in .problems.
shown formats a value for a problem's message, as the package's own
messages do: as JSON (null, [1, 2], "C"). An extension's rules use it
so their messages read like the package's.
ProblemKind
module-attribute
¶
ProblemKind = Literal[
"missing_key",
"invalid_type",
"invalid_value",
"invalid_json",
"unknown_key",
]
Machine-readable classification of a ValidationProblem.
missing_key: a required key (document key or store key) is absent.invalid_type: a value has the wrong structural type (e.g. a string where a mapping is required, a non-JSON-serializable object).invalid_value: a value has an acceptable type but an invalid content (e.g.zarr_format: 2in a v3 document,order: "Q").invalid_json: bytes that do not decode as JSON.unknown_key: a key that an object's type does not declare, where the type is closed (as a closed TypedDict is). Zarr configurations rarely state whether they are closed (zarr-developers/zarr-specs#270 has been open since 2023), and many readers reject such a key. It has its own kind so that a caller who tolerates it can distinguish it from a wrong value, and so that it never hides other problems in the same object.
Problems
module-attribute
¶
Problems: TypeAlias = tuple[ValidationProblem, ...]
Every problem a reader found, in the order it found them.
__all__
module-attribute
¶
MetadataValidationError ¶
Bases: ValueError
Raised when a value fails validation, by the entry points that raise instead of returning problems.
Carries every problem found (not just the first) in .problems, as an
immutable tuple: a raised error is a finished report, and a caller
inspecting it must not be able to edit the record.
Source code in src/zarr_metadata/_json.py
__init__ ¶
__init__(problems: Sequence[ValidationProblem]) -> None
Source code in src/zarr_metadata/_json.py
__reduce__ ¶
__reduce__() -> tuple[
type[MetadataValidationError],
tuple[tuple[ValidationProblem, ...]],
dict[str, object],
]
Source code in src/zarr_metadata/_json.py
ValidationProblem
dataclass
¶
A single problem found in a value: its location, what is wrong, the kind of problem, and the data used in the message.
loc is the path from the root of the checked value to the bad value,
e.g. ("codecs", 0, "name") in a document. An empty loc refers to
the root.
kind classifies the failure for programmatic dispatch; message
is the human-readable description.
input and ctx hold the data in the message, in the same way that
pydantic's ErrorDetails and zod's issues do. input is the JSON
found at loc, e.g. 12 for a gzip level of 12. It is UNSET when
nothing is there (zod does the same for a missing key; pydantic gives
the object that lacks the key), or when the value there is not JSON,
in which case the message shows it. input is the object the caller
passed in, not a copy, as in pydantic: if the caller later changes its
document, input shows the change. ctx holds what was expected,
when that is more than a type:
gt,ge,ltandle: the bounds from the value's type or from a rule, with the names pydantic uses. For example{"ge": 0, "le": 9}for a gziplevel, whose type isAnnotated[int, Interval(ge=0, le=9)].expected: the values of a closed set, like zod'svalues, in the order the message lists them. For example the values of aLiteral, ofnode_type, or ofzarr_format.
Neither field takes part in equality or the repr: two problems are
equal when they have the same location, message and kind. Every
function that returns or raises problems fills input from the value
its caller passed, so a rule only needs to give the location.
Source code in src/zarr_metadata/_json.py
99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 | |
ctx
class-attribute
instance-attribute
¶
ctx: Mapping[str, JSONValue] = dataclasses.field(
default_factory=_no_ctx,
kw_only=True,
compare=False,
repr=False,
)
input
class-attribute
instance-attribute
¶
input: JSONValue | UNSET = dataclasses.field(
default=UNSET, kw_only=True, compare=False, repr=False
)
__init__ ¶
__init__(
loc: tuple[str | int, ...],
message: str,
kind: ProblemKind,
*,
input: JSONValue | UNSET = UNSET,
ctx: Mapping[str, JSONValue] = _no_ctx(),
) -> None
__post_init__ ¶
Source code in src/zarr_metadata/_json.py
shown ¶
value as a problem's message shows it: as JSON (null, [1, 2]), or as its repr when it is not JSON. A value the interpreter will not write (an integer with too many digits, or a value nested too deep) is described instead.