From: Fiona Ebner <f.ebner@proxmox.com>
To: Thomas Lamprecht <t.lamprecht@proxmox.com>,
Proxmox VE development discussion <pve-devel@lists.proxmox.com>
Subject: Re: [pve-devel] [PATCH manager] ui: util: simplify volume_is_qemu_backup again
Date: Thu, 10 Apr 2025 10:29:05 +0200 [thread overview]
Message-ID: <6e6228f1-378b-4fd4-a806-561caad2464c@proxmox.com> (raw)
In-Reply-To: <61890f96-5720-4122-be8c-683adebc9f2c@proxmox.com>
Am 10.04.25 um 10:12 schrieb Thomas Lamprecht:
> Am 10.04.25 um 09:16 schrieb Fiona Ebner:
>> Commit f8087e0f ("ui: fix regression with checking if volume is QEMU
>> backup") opted for making the function support multiple types of
>> callers making the function more complex than it needs to be. Simply
>
> it's a simple if/else though, so complex is really relative.
Yes, I used a relative statement: "more than it needs to be".
>> adapt the rest of the call sites that the commit introducing the
>> regression missed, i.e. commit 3f8246030 ("ui: backup: also check for
>> backup subtype to classify archive").
>>
>> By always checking the subtype, this also makes the function work
>> correctly should there ever be another storage type supporting file
>> restore with different format names than PBS or volid patterns than
>> directory storages.
>
> FWIW I weighted both options when fixing this and used the central
> one by choice for more flexibility, passing opaque objects is a bit
> of a later move at best IMO move to a single string per clearly named
> parameter, or does yours have any advantage?
>
> Some actual type that can be checked at a compile time would be a
> benefit, but that's another language story.
Agreed and I get your point. It just felt more natural to go with the
object approach since all call sites have that very object and would
need to do the very same deconstruction if going with function(volume,
format, subtype). Independent of the chosen approach, keeping it
consistent with the volume_is_lxc_backup() helper is also an advantage.
In any case, nothing urgent in this follow-up and thank you for the
quick fix!
_______________________________________________
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
next prev parent reply other threads:[~2025-04-10 8:29 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-04-10 7:16 Fiona Ebner
[not found] ` <61890f96-5720-4122-be8c-683adebc9f2c@proxmox.com>
2025-04-10 8:29 ` Fiona Ebner [this message]
2025-04-10 8:35 ` Thomas Lamprecht
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=6e6228f1-378b-4fd4-a806-561caad2464c@proxmox.com \
--to=f.ebner@proxmox.com \
--cc=pve-devel@lists.proxmox.com \
--cc=t.lamprecht@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