-
-
Notifications
You must be signed in to change notification settings - Fork 789
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
#[serde(flatten)] doesn't work with #[serde(default)] for externally tagged enums #1626
Comments
Thanks, I would accept a PR to make this work. |
Happy to give it a try, but I haven't dug too much into Serde's internals. Any pointers on where to start? |
|
FTR, the issue isn't restricted to external tagging; other forms of tagging don't make it work, either. |
I encounter the same issue when using #[derive(Deserialize, Debug)]
enum SomeEnum {
A(u32),
B(u32),
#[serde(other)]
C,
}
#[derive(Deserialize, Debug)]
struct SomeStruct {
filler: u32,
#[serde(flatten)]
some_enum: SomeEnum,
} My use-case specifically is to still be able to deserialize a collection of |
This comment was marked as off-topic.
This comment was marked as off-topic.
# Description We've been seeing error message alerts when loading very competition data from the db. This is expected (cf. #2143) however it is pertubating on-call. The alternative would be to downgrade the warning to an error, however I feel we may be losing signal of future breakages in this case. # Changes <!-- List of detailed changes (how the change is accomplished) --> - [x] use serde[(default)] where possible - [x] for score, which is a flattened enum that doesn't support defaults (cf. this [open issue](serde-rs/serde#1626)), we go back to making it an optional. This is fine since with rank-by-surplus we likely no longer need mandatory score anymore anyways. ## How to test Unit test for old transactions data
…tion The `serde` crate has a bug that prevents the proper deserialization of attributes that are using the `flatten` and `default` directives. See [1] and [2]. This bug affects the freshly introduced `ObjectList.types` attribute. It's not possible to deserialize an `ObjectList` that is missing the `apiVersion` and/or the `kind` values. This commit introduces a custom deserializer for the `types` attribute of `ObjectList`. On top of handling the deserialization case, the custom deserializer provides better default values compared to the ones of the stock `TypeMeta`. The `TypeMeta` struct has empty strings as default values. However, in the context of `ObjectList`, proper default values should be `v1` and `List` instead. [1] serde-rs/serde#1626 [2] serde-rs/serde#1879 Signed-off-by: Flavio Castelli <fcastelli@suse.com>
* fix: ObjectList handle missing apiVersion and kind during deserialization The `serde` crate has a bug that prevents the proper deserialization of attributes that are using the `flatten` and `default` directives. See [1] and [2]. This bug affects the freshly introduced `ObjectList.types` attribute. It's not possible to deserialize an `ObjectList` that is missing the `apiVersion` and/or the `kind` values. This commit introduces a custom deserializer for the `types` attribute of `ObjectList`. On top of handling the deserialization case, the custom deserializer provides better default values compared to the ones of the stock `TypeMeta`. The `TypeMeta` struct has empty strings as default values. However, in the context of `ObjectList`, proper default values should be `v1` and `List` instead. [1] serde-rs/serde#1626 [2] serde-rs/serde#1879 Signed-off-by: Flavio Castelli <fcastelli@suse.com> * ObjectList: derive the `Clone` trait Ensure `ObjectList` derive the `Clone` trait. Signed-off-by: Flavio Castelli <fcastelli@suse.com> * chore: fix rustfmt warning Signed-off-by: Flavio Castelli <fcastelli@suse.com> --------- Signed-off-by: Flavio Castelli <fcastelli@suse.com>
any solution so far? |
Given this:
trying to deserialize this yaml:
into SomeStruct panics with a message:
I hoped it would pick up the default value specified for SomeEnum instead...
Playground example.
Is this a bug or is this not supported?
Docs don't cover this, I tried searching issues, but couldn't find anything quite like this.
The text was updated successfully, but these errors were encountered: