Skip to content
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

using #[serde(flatten)] breaks deserializing #33

Open
KeenS opened this issue May 30, 2018 · 5 comments
Open

using #[serde(flatten)] breaks deserializing #33

KeenS opened this issue May 30, 2018 · 5 comments

Comments

@KeenS
Copy link

KeenS commented May 30, 2018

I expected #[serde(flatten)] does not change the behaviour of internal struct, but it changes.

#[derive(Deserialize, Serialize, PartialEq, Debug)]
struct Paginate {
    limit: u64,
    offset: u64,
}

#[derive(Deserialize, Serialize, PartialEq, Debug)]
struct Query {
    #[serde(flatten)]
    paginate: Paginate
}

fn main() {
    let query = "limit=10&offset=0";
    
    println!("{:?}", from_str::<Paginate>(query));
      // -> Ok(Paginate { limit: 10, offset: 0 })
   println!("{:?}", from_str::<Query>(query));
      // -> Err(Error { err: "invalid type: string \"10\", expected u64" })
    println!("{:?}", to_string(Paginate {limit: 10, offset:0}));
      // Ok("limit=10&offset=0")
    println!("{:?}", to_string(Query {paginate: Paginate {limit: 10, offset:0}}));
      // Ok("limit=10&offset=0")
}

I think this is a bug.

@mitsuhiko
Copy link

This is a limitation in serde: serde-rs/serde#1183

@nox
Copy link
Owner

nox commented Apr 15, 2019

Upstream bug was closed.

@nox nox closed this as completed Apr 15, 2019
@mitsuhiko
Copy link

@nox which upstream bug was closed? serde-rs/serde#1183 is still broken.

@nox
Copy link
Owner

nox commented Apr 15, 2019

I shouldn't do triage on a Monday morning.

@nox nox reopened this Apr 15, 2019
@strohel
Copy link

strohel commented May 17, 2020

For reference: there is a work-around to this mentioned in serde_qs docs, which should apply equally to serde_urlencoded.

The work-around has been mentioned in the equivalent issue in serde_qs: samscott89/serde_qs#14 (comment)

ysndr added a commit to flox/runix that referenced this issue Mar 27, 2023
This PR implements nix supported flakerefs.
Unlike the previous implementation all flakerefs are individual (generic) types.
This allows implementing converting to and from string representations on a per-type basis,
rather than necessarily covering all possible references in a single match statement.
As a side effect, implementing flake references one by one,
allowed us to match nix' behavior more closely (#3, #16).

Some flakerefs allow multiple protocols, but are essentially equivalent.
This includes `file`, `tarball`, `git` and "git forges" (e.g. `github`).
Such flakerefs have been implemented as generic types in order to share parsing logic,
and at the same time retain the ability to enforce individual origins statically.
For instance, it is now possible to define a composite type that requires local files (i.e. `git+file`, `path` `[file+]file://` or `[tarball+]file://`).

All tests that existed with the old flake_ref work with the new ones and I added a couple of "roundtrips" to assure, we do not lose information on the way.

I stumbled over a very annoying [`serde` bug](serde-rs/serde#1547 (comment)) that basically says, `deny_unknown_fields` and `flatten` cannot be used together.

That and the fact that `url` queries are not self describing structures (which [triggers](nox/serde_urlencoded#33) another [`serde` bug](serde-rs/serde#1183) related to flattening), lets me wonder if we should use serde at all for query parsing or do the parsing manually, at the cost of legibility (https://github.com/flox/runix/pull/12/files#diff-fa82b2796286fd4622869172f2187af6691578ffbdf972e853826db2d4277fbcR200-R226).
---------

Co-authored-by: Matthew Kenigsberg <mkenigs@users.noreply.github.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants