3 ms·

I enjoyed your blog series on serde perf. One thing I noticed in this example was that the D example worked pretty much exactly like I want serde to work in th

I enjoyed your blog series on serde perf. One thing I noticed in this example was that the D example worked pretty much exactly like I want serde to work in that it was able to deserialize a subset of the overall document and the Coord struct didn't need to exhaustively cover the individual json data objects. If there's a way to do this in serde, an example in the docs would be really helpful.

Gankro 11y ago
I'm pretty sure this is the only way that Serde works? If you tell it do deserialize to a `Point { x: u32, y: u32 }`, it will ignore any additional fields.
- erickt 11y ago
  It doesn't quite yet. By default it errors on unknown fields, and my plan is to add an annotation to ignore it instead. Not quite sure if I got the default behavior correct though. I'm considering flipping it.
  - Gankro 11y ago
    Huh. I tested it out on serde-toml; does it have a bug, then?
erickt 11y ago
Thanks! I need to get back into writing on it. I just pushed up a rust pull parser version here: https://github.com/kostya/benchmarks/pull/54 https://github.com/kostya/benchmarks/pull/54. Is that what you were thinking of?
- grayrest 11y ago
  My wishes are much more prosaic. It's not clear to me just from reading your docs how I can extract data from a JSON file using the pattern this benchmark shows (top level key containing the data, other keys containing metadata about the request) without having to create otherwise useless struct to cover the outer wrapper object. I see you have a reply to Gankro for a non-exhaustive flag and that'd work. As for the default, the current behavior is what I'd expect from a Rust lib given the correctness first mindset of the community but I will always be opting for non-exhaustive because I think most people providing JSON APIs consider additional keys to be backwards compatible (they are in dynamic languages) and I'd prefer my apps to not break in production for no apparent reason.

Gankro 11y ago

I'm pretty sure this is the only way that Serde works? If you tell it do deserialize to a `Point { x: u32, y: u32 }`, it will ignore any additional fields.

erickt 11y ago
It doesn't quite yet. By default it errors on unknown fields, and my plan is to add an annotation to ignore it instead. Not quite sure if I got the default behavior correct though. I'm considering flipping it.
- Gankro 11y ago
  Huh. I tested it out on serde-toml; does it have a bug, then?

erickt 11y ago

Thanks! I need to get back into writing on it. I just pushed up a rust pull parser version here: https://github.com/kostya/benchmarks/pull/54 https://github.com/kostya/benchmarks/pull/54. Is that what you were thinking of?

grayrest 11y ago
My wishes are much more prosaic. It's not clear to me just from reading your docs how I can extract data from a JSON file using the pattern this benchmark shows (top level key containing the data, other keys containing metadata about the request) without having to create otherwise useless struct to cover the outer wrapper object. I see you have a reply to Gankro for a non-exhaustive flag and that'd work. As for the default, the current behavior is what I'd expect from a Rust lib given the correctness first mindset of the community but I will always be opting for non-exhaustive because I think most people providing JSON APIs consider additional keys to be backwards compatible (they are in dynamic languages) and I'd prefer my apps to not break in production for no apparent reason.