public inbox for pve-devel@lists.proxmox.com
 help / color / mirror / Atom feed
From: Wolfgang Bumiller <w.bumiller@proxmox.com>
To: "Fabian Grünbichler" <f.gruenbichler@proxmox.com>
Cc: Proxmox VE development discussion <pve-devel@lists.proxmox.com>
Subject: Re: [pve-devel] [RFC PATCH common] section config: implement array support
Date: Wed, 10 May 2023 15:56:21 +0200	[thread overview]
Message-ID: <20230510135621.7hxaccrdl44albfd@casey.proxmox.com> (raw)
In-Reply-To: <1683718319.ft0ifv3hyf.astroid@yuna.none>

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




  reply	other threads:[~2023-05-10 13:56 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-05-10  8:18 Dominik Csapak
2023-05-10 11:48 ` Fabian Grünbichler
2023-05-10 13:56   ` Wolfgang Bumiller [this message]
2023-05-11 11:30     ` Dominik Csapak

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20230510135621.7hxaccrdl44albfd@casey.proxmox.com \
    --to=w.bumiller@proxmox.com \
    --cc=f.gruenbichler@proxmox.com \
    --cc=pve-devel@lists.proxmox.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Service provided by Proxmox Server Solutions GmbH | Privacy | Legal