From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <d.csapak@proxmox.com> 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 7D89C9E5F3 for <pbs-devel@lists.proxmox.com>; Mon, 27 Nov 2023 15:57:24 +0100 (CET) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id 64FB5A29F for <pbs-devel@lists.proxmox.com>; Mon, 27 Nov 2023 15:57:24 +0100 (CET) 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) server-digest SHA256) (No client certificate requested) by firstgate.proxmox.com (Proxmox) with ESMTPS for <pbs-devel@lists.proxmox.com>; Mon, 27 Nov 2023 15:57:22 +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 9502B44BA0; Mon, 27 Nov 2023 15:57:22 +0100 (CET) Message-ID: <b48d3f08-71cd-42d8-a98f-7de23c240504@proxmox.com> Date: Mon, 27 Nov 2023 15:57:20 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Beta Content-Language: en-US To: Wolfgang Bumiller <w.bumiller@proxmox.com> Cc: Thomas Lamprecht <t.lamprecht@proxmox.com>, Proxmox Backup Server development discussion <pbs-devel@lists.proxmox.com> References: <20230801092954.1686860-1-d.csapak@proxmox.com> <20230801092954.1686860-2-d.csapak@proxmox.com> <924f16d9-542a-4dfc-b374-db7ab7ad589b@proxmox.com> <43fbabe3-1c51-4d6b-ba92-6e570b985d62@proxmox.com> <d8f7bdf9-6a63-4e06-aaea-3ae1bca95caa@proxmox.com> <391ac639-fad7-45d0-97eb-cdb1cba70d08@proxmox.com> <g5wa657jsmdz4rjpyhz2ccklbadsbmeyfwgxdlauhh2ldqdvmq@r6c3dj5a4aq2> From: Dominik Csapak <d.csapak@proxmox.com> In-Reply-To: <g5wa657jsmdz4rjpyhz2ccklbadsbmeyfwgxdlauhh2ldqdvmq@r6c3dj5a4aq2> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-SPAM-LEVEL: Spam detection results: 0 AWL 0.017 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. [serde.rs] Subject: Re: [pbs-devel] [RFC PATCH proxmox-backup 1/3] api-types: make UploadStatistic an api type X-BeenThere: pbs-devel@lists.proxmox.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: Proxmox Backup Server development discussion <pbs-devel.lists.proxmox.com> List-Unsubscribe: <https://lists.proxmox.com/cgi-bin/mailman/options/pbs-devel>, <mailto:pbs-devel-request@lists.proxmox.com?subject=unsubscribe> List-Archive: <http://lists.proxmox.com/pipermail/pbs-devel/> List-Post: <mailto:pbs-devel@lists.proxmox.com> List-Help: <mailto:pbs-devel-request@lists.proxmox.com?subject=help> List-Subscribe: <https://lists.proxmox.com/cgi-bin/mailman/listinfo/pbs-devel>, <mailto:pbs-devel-request@lists.proxmox.com?subject=subscribe> X-List-Received-Date: Mon, 27 Nov 2023 14:57:24 -0000 On 11/27/23 13:44, Wolfgang Bumiller wrote: > On Mon, Nov 27, 2023 at 11:17:49AM +0100, Dominik Csapak wrote: >> On 11/27/23 11:12, Thomas Lamprecht wrote: >>> On 27.11.23 11:01, Dominik Csapak wrote: >>>> On 11/27/23 10:52, Thomas Lamprecht wrote: >>>>> On 01.08.23 11:29, Dominik Csapak wrote: >>>>>> +#[api()] >>>>>> +#[derive(Copy, Clone, Serialize, Deserialize)] >>>>> >>>>> misses: >>>>> >>>>> #[serde(rename_all = "kebab-case")] >>>>> >>>>> or does that break manifest? >>>> >>>> it shouldn't since we only save it in the 'unprotected' field that is a 'Value' >>>> but i'll check >>> >>> I did not mean breakage as in "might break signatures", but as in >>> backward/forward compat to any of our code/tools using that field >>> already (tbh. not sure from top of my head if serde json magically >>> falls back to field casing variants, e.g., check if foo-bar is there >>> if not take foo_bar, I think not, so that's why I asked - should have >>> said so in my first response). >> >> mhmm.. we only ever write that once (during backup finish) and never read >> it anywhere (until my patch) so it couldn't break any existing code. >> >> adding the rename now would only affect new backups, but you might be >> right that deserializing older backups might not be working then. >> >> again, i'll check > > in theory we could also add a #[serde(alias = "...")]. The docs say > "deserialize (...) from the given name *or* from its Rust name"[1], but > I'm not sure if "its Rust name" then means the original or the > `rename_all`-transformed version ;-) > Also, we don't currently directly support this in the proxmox-schema - > but we do in perl iirc, so we might as well add that to rust? > > [1] https://serde.rs/field-attrs.html btw. i can confirm that if i use serdes rename_all = "kebab-case" we can't deserialize it anymore (did not find 'compressed-size') but if i add alias = "compressed_size" it can deserialize from existing manifests, and serializes as 'compressed-size'