public inbox for pbs-devel@lists.proxmox.com
 help / color / mirror / Atom feed
From: Wolfgang Bumiller <w.bumiller@proxmox.com>
To: Dietmar Maurer <dietmar@proxmox.com>,
	Thomas Lamprecht <t.lamprecht@proxmox.com>
Cc: Proxmox Backup Server development discussion
	<pbs-devel@lists.proxmox.com>
Subject: Re: [pbs-devel] applied: [PATCH proxmox-backup] api2/config/tape_backup_job: fix duplicate id parameter
Date: Wed, 24 Feb 2021 09:35:42 +0100	[thread overview]
Message-ID: <20210224083542.spkz4mi5jrgge23x@wobu-vie.proxmox.com> (raw)
In-Reply-To: <747410998.16.1614151735303@webmail.proxmox.com>

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 {
        <rest>
    }

But that probably gets annoying very quickly...?




  reply	other threads:[~2021-02-24  8:35 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-02-23 14:54 [pbs-devel] " Dominik Csapak
2021-02-23 16:26 ` [pbs-devel] applied: " Dietmar Maurer
2021-02-23 17:00   ` Thomas Lamprecht
2021-02-23 19:27     ` Dietmar Maurer
2021-02-24  6:13       ` Dietmar Maurer
2021-02-24  7:28         ` Dietmar Maurer
2021-02-24  8:35           ` Wolfgang Bumiller [this message]
2021-02-24  8:42             ` Dietmar Maurer
2021-02-24  9:02               ` Wolfgang Bumiller
2021-02-24  9:47                 ` Dietmar Maurer
2021-02-25  8:53                   ` Dietmar Maurer

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=20210224083542.spkz4mi5jrgge23x@wobu-vie.proxmox.com \
    --to=w.bumiller@proxmox.com \
    --cc=dietmar@proxmox.com \
    --cc=pbs-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