Public alternative to Content and ContentRefDeserializer? #1947
Comments
|
Yes, it would be reasonable for someone to maintain both of those types in a separate crate. |
|
i.e. extract it from serde into a separate crate, and then both serde and my crate depend on it? I can look into doing that. |
bors bot
added a commit
to Metaswitch/swagger-rs
that referenced
this issue
Jan 12, 2021
135: Workaround API break on private API in Serde 1.0.119 r=richardwhiuk a=richardwhiuk We are using a private API in serde, and they've changed the API in a patch release to remind us this is wrong: serde-rs/serde@dd1f4b4 That's annoying, but there's no easy viable alternative. This API is used by serde_derive on an untagged enum ( see https://github.com/serde-rs/serde/blob/b0c99ed761d638f2ca2f0437522e6c35ad254d93/serde_derive/src/de.rs#L1627-L1645 ), which is basically what we have. We can't use serde_derive, because we want specific semantics. The only alternative is re-implementing the `ContentRefDeserializer` and `Content` objects, which is clearly worse than depending on this private API. I've asked in Discord and raised serde-rs/serde#1947 to query the serde devs. Signed-off-by: Richard Whitehouse <[email protected]> Co-authored-by: Richard Whitehouse <[email protected]>
richardwhiuk
added a commit
to Metaswitch/swagger-rs
that referenced
this issue
Jan 18, 2021
135: Workaround API break on private API in Serde 1.0.119 r=richardwhiuk a=richardwhiuk We are using a private API in serde, and they've changed the API in a patch release to remind us this is wrong: serde-rs/serde@dd1f4b4 That's annoying, but there's no easy viable alternative. This API is used by serde_derive on an untagged enum ( see https://github.com/serde-rs/serde/blob/b0c99ed761d638f2ca2f0437522e6c35ad254d93/serde_derive/src/de.rs#L1627-L1645 ), which is basically what we have. We can't use serde_derive, because we want specific semantics. The only alternative is re-implementing the `ContentRefDeserializer` and `Content` objects, which is clearly worse than depending on this private API. I've asked in Discord and raised serde-rs/serde#1947 to query the serde devs. Signed-off-by: Richard Whitehouse <[email protected]> Co-authored-by: Richard Whitehouse <[email protected]>
|
Did someone extract it somewhere? I was implementing the approach suggested here #745 (comment) for versioning but I wanted to error out if the version is matching but the JSON is invalid for that version. Seems like I a visitor like this one. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
We are currently using Content and ContentRefDeserializer from serde::private (which has been renamed serde::__private in Serde 1.0.119) which has obviously (and intentionally) broken our usage. 😞 I can appreciate why you want to discourage public use of private APIs though ❤️ .
We are using this to decode an untagged enum in a specific fashion - we need specific behaviour depending on whether it matches one, or more than one of the enum options. Largely however, we want to match the behaviour given by serde_derive though.
As far as I can tell, this isn't exposed publicly - does anyone know the right way to do this?
An example of our usage is in https://github.com/Metaswitch/swagger-rs/blob/fdd728f0088659446215ab70ea4abcd2a91ca304/src/one_any_of.rs#L62-L73
I don't think we can move to using
serde_deriveand (thusserde_derive::de::deserialize_untagged_enum) which seems to be the only supported path of calling this, as we want specific behaviour which that doesn't implement.In the short term, we'll move to
__private, but clearly that's not a sustainable fix!The text was updated successfully, but these errors were encountered: