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) server-digest SHA256) (No client certificate requested) by lists.proxmox.com (Postfix) with ESMTPS id 3FD0F69687 for ; Wed, 24 Feb 2021 09:35:44 +0100 (CET) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id 2FF9726FE2 for ; Wed, 24 Feb 2021 09:35:44 +0100 (CET) Received: from proxmox-new.maurer-it.com (proxmox-new.maurer-it.com [212.186.127.180]) (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 id A62FF26FD8 for ; Wed, 24 Feb 2021 09:35:43 +0100 (CET) Received: from proxmox-new.maurer-it.com (localhost.localdomain [127.0.0.1]) by proxmox-new.maurer-it.com (Proxmox) with ESMTP id 6A496457E9 for ; Wed, 24 Feb 2021 09:35:43 +0100 (CET) Date: Wed, 24 Feb 2021 09:35:42 +0100 From: Wolfgang Bumiller To: Dietmar Maurer , Thomas Lamprecht Cc: Proxmox Backup Server development discussion Message-ID: <20210224083542.spkz4mi5jrgge23x@wobu-vie.proxmox.com> References: <20210223145403.2126-1-d.csapak@proxmox.com> <1716330912.3668.1614097567040@webmail.proxmox.com> <16b17f26-ec37-fd9f-004d-2fd146a4d900@proxmox.com> <1644937938.10.1614108472151@webmail.proxmox.com> <654681787.11.1614147199226@webmail.proxmox.com> <747410998.16.1614151735303@webmail.proxmox.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <747410998.16.1614151735303@webmail.proxmox.com> User-Agent: NeoMutt/20180716 X-SPAM-LEVEL: Spam detection results: 0 AWL 0.044 Adjusted score from AWL reputation of From: address KAM_DMARC_STATUS 0.01 Test Rule for DKIM or SPF Failure with Strict Alignment RCVD_IN_DNSWL_MED -2.3 Sender listed at https://www.dnswl.org/, medium trust SPF_HELO_NONE 0.001 SPF: HELO does not publish an SPF Record SPF_PASS -0.001 SPF: sender matches SPF record Subject: Re: [pbs-devel] applied: [PATCH proxmox-backup] api2/config/tape_backup_job: fix duplicate id parameter X-BeenThere: pbs-devel@lists.proxmox.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: Proxmox Backup Server development discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Feb 2021 08:35:44 -0000 On Wed, Feb 24, 2021 at 08:28:54AM +0100, Dietmar Maurer wrote: > Seems there is another problem with the Updater: > > I can delete properties if I use normal rust naming, e.g. > > job.update_from(update, "eject_media")?; > > But it does not work with kebab-case: > > job.update_from(update, "eject-media")?; // this fails silently > > Please can we: > > - support kebab-case ^ that's a quick one, fix for this is in git, will bump & upload in a bit > - raise error with unknown property names ^ this is a bit more involved due to flattening One option would be to generate an enum schema for deletable fields, though this requires a change to how we represent enums, so I can nest the flattened objects in there. Another would be to just generate a "string" schema with a verify function which uses the existing property iterators to look for invalid names. (This could probably even generate a lazy_static HashSet for faster checks). On Tue, Feb 23, 2021 at 06:00:33PM +0100, Thomas Lamprecht wrote: > On 23.02.21 17:26, Dietmar Maurer wrote: > > applied > > did you read that part: > > On 23.02.21 15:54, Dominik Csapak wrote: > > i am *really* not sure if this is the correct way @Wolfgang, is > > there another wayt to selectively use the struct members for the > > Updater? > > > This makes the ID optional in the schema, which is weird for an API call > with {id} in its url (which means that without ID this can never be reached). Now it's getting tough. Somehow I did not think about that :-) But sure, we often need a way to identify entries, so maybe add a `#[updater(id_property)]` attribute. (Or name it `non_optional` but that may be too unspecific of a name.) Or are there any other reasons why a field would behave this way? An alternative of course would be to split the object up and flatten the data part: #[api] struct MyType { id: String, #[serde(flatten)] contents: MyTypeContents, } #[api] struct MyTypeContents { } But that probably gets annoying very quickly...?