-
-
Notifications
You must be signed in to change notification settings - Fork 774
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
Deserializing borrowed string when it contains \n escape #1413
Comments
That is not the error I get when running the program you gave. Your input file contains |
Hey! Sorry for the confusion. I had edited the JSON because the actual file is 5mb big. I botched it while doing so. I've created a playground that exhibits the error: |
Here is a minimized example (same as your code but with extraneous fields removed): https://play.rust-lang.org/?edition=2015&gist=378fc363d8ec9752d4e19f4500c07851 Here you need to consider what you expect |
Doesn't (in your example) struct Media {
description: String
} would obviously work, but I wanted to play around the serde zero-copy deserialization feature. |
Well the length of the string in |
For anyone landing on this issue (like I did), I think a bit more context may be useful. The reason serde can't deserialize into a borrowed string is that it needs to modify (unescape) the encoded json, which requires ownership. That said, it appears you can get around this by using a If this is incorrect please let me know (I'm still somewhat new to Rust). |
This seems like a case where the error messaging describing the problem could be improved. I can accept that the lib needs to own the data once the "escape" dilemma is explained to me (thanks @michael-grunder ) however when I first saw this error message in my own code I was baffled as to why a borrowed string posed a problem here. Perhaps serde's error message could better explain why the distinction matters. |
@michael-grunder as an alternative, is there a way to specify a borrowed string from the json? |
This commit fixes two bugs dealing with ClickHouse, and adds regressions for them. The first is about deserialization of structs which have a `&str` field. `serde_json` is generally fine about zero-copy, except if the string requires escaping. In that case, it can no longer deserialize the data into a `&str`, since it must take ownership and manipulate the returned buffer. This requires replacing `&'a str` with `Cow<'a, str>` in the DB model types, specifically for the timeseries key fields. See serde-rs/serde#1413 for more details. Note that we also parse all string datum from the DB as `String` directly, rather than as `&str`, again to avoid this (and because we'll be converting it to an owned representation soon anyway). The second bug is handling a ClickHouse oddity. By default, 64-bit integer types are returned as _quoted_ strings. As in, `"1"` instead of `1`. This is apparently to support JavaScript's JSON implementation, but in any case it's not the behavior we expect or want. There is thankfully a setting to turn this off, which the database client object now sets when it makes requests returning JSON data. See ClickHouse/ClickHouse#2375 for more details.
This commit fixes two bugs dealing with ClickHouse, and adds regressions for them. The first is about deserialization of structs which have a `&str` field. `serde_json` is generally fine about zero-copy, except if the string requires escaping. In that case, it can no longer deserialize the data into a `&str`, since it must take ownership and manipulate the returned buffer. This requires replacing `&'a str` with `Cow<'a, str>` in the DB model types, specifically for the timeseries key fields. See serde-rs/serde#1413 for more details. Note that we also parse all string datum from the DB as `String` directly, rather than as `&str`, again to avoid this (and because we'll be converting it to an owned representation soon anyway). The second bug is handling a ClickHouse oddity. By default, 64-bit integer types are returned as _quoted_ strings. As in, `"1"` instead of `1`. This is apparently to support JavaScript's JSON implementation, but in any case it's not the behavior we expect or want. There is thankfully a setting to turn this off, which the database client object now sets when it makes requests returning JSON data. See ClickHouse/ClickHouse#2375 for more details.
This commit fixes two bugs dealing with ClickHouse, and adds regressions for them. The first is about deserialization of structs which have a `&str` field. `serde_json` is generally fine about zero-copy, except if the string requires escaping. In that case, it can no longer deserialize the data into a `&str`, since it must take ownership and manipulate the returned buffer. There are a few ways around this, but this commit opts for the simplest -- using a owned `String` instead of a `&str`. The string is immediately moved into a `Measurement`, which takes ownership anyway, so this is the most straightfoward choice. See serde-rs/serde#1413 for more details. Note that we also parse all string datum from the DB as `String` directly, rather than as `&str`, again to avoid this. The second bug is handling a ClickHouse oddity. By default, 64-bit integer types are returned as _quoted_ strings. As in, `"1"` instead of `1`. This is apparently to support JavaScript's JSON implementation, but in any case it's not the behavior we expect or want. There is thankfully a setting to turn this off, which the database client object now sets when it makes requests returning JSON data. See ClickHouse/ClickHouse#2375 for more details.
This commit fixes two bugs dealing with ClickHouse, and adds regressions for them. The first is about deserialization of structs which have a `&str` field. `serde_json` is generally fine about zero-copy, except if the string requires escaping. In that case, it can no longer deserialize the data into a `&str`, since it must take ownership and manipulate the returned buffer. There are a few ways around this, but this commit opts for the simplest -- using a owned `String` instead of a `&str`. The string is immediately moved into a `Measurement`, which takes ownership anyway, so this is the most straightfoward choice. See serde-rs/serde#1413 for more details. Note that we also parse all string datum from the DB as `String` directly, rather than as `&str`, again to avoid this. The second bug is handling a ClickHouse oddity. By default, 64-bit integer types are returned as _quoted_ strings. As in, `"1"` instead of `1`. This is apparently to support JavaScript's JSON implementation, but in any case it's not the behavior we expect or want. There is thankfully a setting to turn this off, which the database client object now sets when it makes requests returning JSON data. See ClickHouse/ClickHouse#2375 for more details.
This commit fixes two bugs dealing with ClickHouse, and adds regressions for them. The first is about deserialization of structs which have a `&str` field. `serde_json` is generally fine about zero-copy, except if the string requires escaping. In that case, it can no longer deserialize the data into a `&str`, since it must take ownership and manipulate the returned buffer. There are a few ways around this, but this commit opts for the simplest -- using a owned `String` instead of a `&str`. The string is immediately moved into a `Measurement`, which takes ownership anyway, so this is the most straightfoward choice. See serde-rs/serde#1413 for more details. Note that we also parse all string datum from the DB as `String` directly, rather than as `&str`, again to avoid this. The second bug is handling a ClickHouse oddity. By default, 64-bit integer types are returned as _quoted_ strings. As in, `"1"` instead of `1`. This is apparently to support JavaScript's JSON implementation, but in any case it's not the behavior we expect or want. There is thankfully a setting to turn this off, which the database client object now sets when it makes requests returning JSON data. See ClickHouse/ClickHouse#2375 for more details.
We are currently deserializing the query string into `Vec<(&str, &str)>`. `serde_urlencoded` panics if the input string slice contains escaped data, since in that case it needs to allocate a new `String` to unescape the input string slice's contents. Instead of deserializing to `Vec<(String, String)>`, we can instead use `Cow<'a, str>` so that deserialization only allocates when strictly required. Reference: serde-rs/serde#1413 (comment)
We are currently deserializing the query string into `Vec<(&str, &str)>`. `serde_urlencoded` panics if the input string slice contains escaped data, since in that case it needs to allocate a new `String` to unescape the input string slice's contents. Instead of deserializing to `Vec<(String, String)>`, we can instead use `Cow<'a, str>` so that deserialization only allocates when strictly required. Reference: serde-rs/serde#1413 (comment)
…ta (#1058) We are currently deserializing the query string into `Vec<(&str, &str)>`. `serde_urlencoded` panics if the input string slice contains escaped data, since in that case it needs to allocate a new `String` to unescape the input string slice's contents. Instead of deserializing to `Vec<(String, String)>`, we can instead use `Cow<'a, str>` so that deserialization only allocates when strictly required. Reference: serde-rs/serde#1413 (comment)
…y string data (#1058) We are currently deserializing the query string into `Vec<(&str, &str)>`. `serde_urlencoded` panics if the input string slice contains escaped data, since in that case it needs to allocate a new `String` to unescape the input string slice's contents. Instead of deserializing to `Vec<(String, String)>`, we can instead use `Cow<'a, str>` so that deserialization only allocates when strictly required. Reference: serde-rs/serde#1413 (comment)
…y string data (#1058) We are currently deserializing the query string into `Vec<(&str, &str)>`. `serde_urlencoded` panics if the input string slice contains escaped data, since in that case it needs to allocate a new `String` to unescape the input string slice's contents. Instead of deserializing to `Vec<(String, String)>`, we can instead use `Cow<'a, str>` so that deserialization only allocates when strictly required. Reference: serde-rs/serde#1413 (comment)
invalid type: string. expected a borrowed string
Hey!
I have this very simple example:
This is the input json:
I'm getting the error:
What did I do wrong? I did read the docs but couldn't figure it out.
The text was updated successfully, but these errors were encountered: