rather than just always allowing additional properties, only return
true if any of the available schemas allows it
Signed-off-by: Wolfgang Bumiller <w.bumiller@proxmox.com>
A 'oneOf' schema is basically exactly what a rust `enum` is.
Exactly one of the possible values must match the data.
This should ultimately be the base to allow using the
`#[api]` macro on a newtype style enum as well as using this
schema as a configuration for our section config parser.
Signed-off-by: Wolfgang Bumiller <w.bumiller@proxmox.com>
Reviewed-by: Lukas Wagner <l.wagner@proxmox.com>
If there is only one error, output in a single line, without any
excessive newlines at the end. If there are multiple errors, show them
in a bulleted list.
Signed-off-by: Gabriel Goller <g.goller@proxmox.com>
This provides `proxmox_schema::property_string::PropertyString<T>` for
a typed property-string.
To facilitate this, this introduces
`proxmox_schema:🇩🇪:SchemaDeserializer` which is a serde deserializer
for property strings given a schema.
This basically maps to one of `de::SeqAccess` (for array schemas) or
`de::MapAccess` (for object schemas).
Additionally, a `de::NoSchemaDeserializer` is added, since properties
within the strings may have string schemas with no format to it, while
the type we serialize to may ask for an array (a simple "list") via
serde.
The deserializers support borrowing, for which a helper `Cow3` needed
to be added, since property strings support quoting with escape
sequences where an intermediate string would be allocated and with an
intermediate lifetime distinct from the `'de` lifetime.
A `de::verify` module is added which uses serde infrastructure to
validate schemas without first having to deserialize a complete
`serde_json::Value`.
For serialization, `proxmox_schema::ser::PropertyStringSerializer` is
added split into similar parts `ser::SerializeStruct` and
`ser::SerializeSeq` at the top level, and the same prefixed with
`Element` for inside the actual string. This should also properly
quote the contents if required.
Signed-off-by: Wolfgang Bumiller <w.bumiller@proxmox.com>
with two variants:
(expr, expr) => assumes that the second is an 'Error'
(expr, (tt)+) => passes the tt through anyhow::format_err
also added tests
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
'unwrap_' because they will panic and as `const fn` since
panic in const fn is now possible
Note that const evaluation will only be triggered when
actually used in const context, so to ensure *compile time*
checks, use something like this:
const FOO_SCHEMA: &AllOfSchema =
SomeType::API_SCHEMA.unwrap_all_of_schema();
then_use(FOO_SCHEMA);
or to use the list of enum values of an enum string type
with compile time checks:
const LIST: &'static [EnumEntry] =
AnEnumStringType::API_SCHEMA
.unwrap_string_schema()
.unwrap_format()
.unwrap_enum_format();
for values in LIST {
...
}
Signed-off-by: Wolfgang Bumiller <w.bumiller@proxmox.com>
This allows free form text to exist within property strings,
quoted, like:
key="A value with \"quotes, also commas",key2=value2
or also:
"the value for a default_key",key2=value2
And drop ';' as a key=value separator since those are meant
for arrays inside property strings...
Signed-off-by: Wolfgang Bumiller <w.bumiller@proxmox.com>
for ease of use implement these traits for ParameterError:
* From<(&str, Error)>
* From<(String, Error)>
* Extend<(String, Error)>
* Extend<(&str, Error)>
* IntoIterator<Item = (String, Error)>
and add the following methods:
* fn into_inner(self) -> Vec<(String, Error)>;
Signed-off-by: Wolfgang Bumiller <w.bumiller@proxmox.com>
by replacing the whole Vec.
if we ever want to support adding/removing/modifying elements of a Vec
via the Updater, we'd need to extend it anyway (or use a custom
updater).
Suggested-by: Dominik Csapak <d.csapak@proxmox.com>
Signed-off-by: Fabian Grünbichler <f.gruenbichler@proxmox.com>
