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 A1A7D69695 for ; Wed, 24 Feb 2021 10:02:39 +0100 (CET) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id 9069E27253 for ; Wed, 24 Feb 2021 10:02:09 +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) server-digest SHA256) (No client certificate requested) by firstgate.proxmox.com (Proxmox) with ESMTPS id 1388F27245 for ; Wed, 24 Feb 2021 10:02:09 +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 D71AC441E7 for ; Wed, 24 Feb 2021 10:02:08 +0100 (CET) Date: Wed, 24 Feb 2021 10:02:07 +0100 (CET) From: Wolfgang Bumiller To: Dietmar Maurer , Thomas Lamprecht Cc: Proxmox Backup Server development discussion Message-ID: <469741124.32.1614157327650@webmail.proxmox.com> In-Reply-To: <1545584386.29.1614156141658@webmail.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> <20210224083542.spkz4mi5jrgge23x@wobu-vie.proxmox.com> <1545584386.29.1614156141658@webmail.proxmox.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Priority: 3 Importance: Normal X-Mailer: Open-Xchange Mailer v7.10.4-Rev18 X-Originating-Client: open-xchange-appsuite X-SPAM-LEVEL: Spam detection results: 0 AWL 0.043 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 09:02:39 -0000 > On 02/24/2021 9:42 AM Dietmar Maurer wrote: > > > > > Please can we: > > > > > > - support kebab-case > > > > ^ that's a quick one, fix for this is in git, will bump & upload in a > > bit > > Ok, thanks! > > > > > > - 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). > > Sound too complex for now ... > I guess this is not really important - just thought it would be nice to have. > > > 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 :-) > > Cant we simple omit fixed properties from the Updater? I could try. I'd have to split out the Builder functionality of the Updatable trait, which is currently what allows `Option` to be generically implemented without specialization, but I could in theory generate implementations for Option types on the fly as well... (Currently there's a generic `impl Updatable for Option` going like this: if the option is Some() already, then update_from(), otherwise try_build_from().)