On Wed, May 10, 2023 at 01:48:11PM +0200, Fabian Grünbichler wrote:
> On May 10, 2023 10:18 am, Dominik Csapak wrote:
> > @@ -124,6 +130,24 @@ sub updateSchema {
> >
> > next if defined($filter_type) && !defined($copts->{$p});
> >
> > + if ($propertyList->{$p}->{type} eq 'array') {
> > + $props->{$p} = $copy_property->($propertyList->{$p}->{items});
> > + $props->{$p}->{optional} = $propertyList->{$p}->{optional} // 0;
> > +
> > + # add index for all non property strings
> > + if (!defined($propertyList->{$p}->{items}->{format})) {
> > + $props->{$p}->{requires} = "$p-index";
> > + $props->{"$p-index"} = {
> > + type => 'integer',
> > + minimum => 0,
> > + description => "Determines which array element to update (0
> > is the first element).",
> > + optional => $propertyList->{$p}->{optional} // 0,
> > + },
>
> this is not how it's implemented in our Rust schema..
>
> I guess we could make the index optional always and implement similar
> support on the rust side as well? no index -> wholesale replacement.
> index -> partial update? if we do partial updaters for arrays, it would
> also be nice to have them for property strings as well (although that is
> of course more work to implement, but it would have more potential for
> UX improvement) - a property string is just an object after all, so the
> key is the "index".
I'm not convinced this update schema should be there at all.
1)
I think the only place this really affects is the CLI.
Sure, accessing an individual element might "feel nicer" when writing
the UI in *some* ways, but really, the UI usually already has the whole
array already and can just include it. (Plus, these are never actually
that big!)
On the CLI, however, we have to actually type out these parameters, and
they feel a *lot* bigger there.
And how would I:
- add one or multiple values
- insert one or multiple values
- update multiple values
- delete multiple values
The startup times of those perl binaries is already huge, if I have to
reload the whole API for every single element in an array I want to
change, that's quite... bad.
2)
We already have --netX, --mpX, ... which aren't arrays, and if we start
generating schemas like this, it might be worth considering whether we'd
ever want to change that in the future?
3)
Sometimes I kind of wish we'd just use 'json paths' for the keys...
Or, well, generate `--foo.bar` update-schemas for property strings and
introduce support for `patternProperties` (see 10.3.2.2. in the json
schema core spec here[1]), for arrays to support `--foo[3]=bar`, but
generating these things doesn't actually scale too great, eg. think of
an array of property strings...
I mean... It would be actually nice if I could do
`--net0.link-down=true` instead of copying the entire network string...
[1] https://json-schema.org/draft/2020-12/json-schema-core.html#section-10.3.2.2
_______________________________________________
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
