From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from firstgate.proxmox.com (firstgate.proxmox.com [212.224.123.68]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by lists.proxmox.com (Postfix) with ESMTPS id 449709A9AB for ; Wed, 10 May 2023 15:56:54 +0200 (CEST) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id 214E22925A for ; Wed, 10 May 2023 15:56:24 +0200 (CEST) Received: from proxmox-new.maurer-it.com (proxmox-new.maurer-it.com [94.136.29.106]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by firstgate.proxmox.com (Proxmox) with ESMTPS for ; Wed, 10 May 2023 15:56:22 +0200 (CEST) Received: from proxmox-new.maurer-it.com (localhost.localdomain [127.0.0.1]) by proxmox-new.maurer-it.com (Proxmox) with ESMTP id 4A0AB47EEF for ; Wed, 10 May 2023 15:56:22 +0200 (CEST) Date: Wed, 10 May 2023 15:56:21 +0200 From: Wolfgang Bumiller To: Fabian =?utf-8?Q?Gr=C3=BCnbichler?= Cc: Proxmox VE development discussion Message-ID: <20230510135621.7hxaccrdl44albfd@casey.proxmox.com> References: <20230510081829.752401-1-d.csapak@proxmox.com> <1683718319.ft0ifv3hyf.astroid@yuna.none> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <1683718319.ft0ifv3hyf.astroid@yuna.none> X-SPAM-LEVEL: Spam detection results: 0 AWL 0.133 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DMARC_MISSING 0.1 Missing DMARC policy KAM_DMARC_STATUS 0.01 Test Rule for DKIM or SPF Failure with Strict Alignment SPF_HELO_NONE 0.001 SPF: HELO does not publish an SPF Record SPF_PASS -0.001 SPF: sender matches SPF record T_SCC_BODY_TEXT_LINE -0.01 - URIBL_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to URIBL was blocked. See http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block for more information. [json-schema.org] Subject: Re: [pve-devel] [RFC PATCH common] section config: implement array support X-BeenThere: pve-devel@lists.proxmox.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: Proxmox VE development discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 May 2023 13:56:54 -0000 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