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

Cannot deserialize 00:00:00 from MariaDB into time::Time and chrono::NaiveTime #418

Closed
leeola opened this issue Jun 17, 2020 · 5 comments · Fixed by #460
Closed

Cannot deserialize 00:00:00 from MariaDB into time::Time and chrono::NaiveTime #418

leeola opened this issue Jun 17, 2020 · 5 comments · Fixed by #460

Comments

@leeola
Copy link

leeola commented Jun 17, 2020

Not sure how to reproduce this, but lets start with what I do know.

Sqlx version: 0.3.5
Sqlx Features: mysql, chrono, time. [1]
Rust toolchain: nightly-2020-06-01
Database: MariaDB 10.3.18
Column type: time
Example values: 00:00:00, 02:00:00
Error message:

thread 'test_name' panicked at 'index out of bounds: the len is 0 but the index is 0', /Users/me/.cargo/registry/src/gh.neting.cc-1ecc6299db9ec823/sqlx-core-0.3.5/src/io/buf.rs:55:19

I receive the above error message any time I try to query_as a MariaDB time column type into either a chrono::NaiveTime or a time::Time type. I'm also unsure about a workaround, as I can't seem deserialize that time value into a String, Vec<u8> or something comparable, either.

Thoughts?

[1]: I've used chrono and time features in combination, as well as individually.

@leeola
Copy link
Author

leeola commented Jun 17, 2020

I noticed that the time and chrono type tests have a micro suffix on TIME, example:

"TIME '05:10:20.115100'" == NaiveTime::from_hms_micro(5, 10, 20, 115100)

None of our time values have this. At least, not visibly in my queries. Could this be causing the problem?

@leeola
Copy link
Author

leeola commented Jun 17, 2020

Poking around blindly in the tests, with test:

    test_type!(chrono_time<NaiveTime>(
        MySql,
        "TIME '05:10:20.115100'" == NaiveTime::from_hms_micro(5, 10, 20, 115100),
        "TIME '05:10:20'" == NaiveTime::from_hms(5, 10, 20),
        "TIME '00:00:00'" == NaiveTime::from_hms(0,0,0),
        "TIME '02:00:00'" == NaiveTime::from_hms(2,0,0)
    ));

(modified from: https://github.com/launchbadge/sqlx/blob/master/tests/mysql/types.rs#L52-L55)
I got the following failure:

---- chrono::test_prepared_type_chrono_time stdout ----
thread 'chrono::test_prepared_type_chrono_time' panicked at 'assertion failed: self.remaining() >= 1', /Users/me/.rustup/toolchains/nightly-2020-06-01-x86_64-apple-darwin/lib/rustlib/src/rust/src/libcore/macros/mod.rs:10:9
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace


failures:
    chrono::test_prepared_type_chrono_time

With "TIME '00:00:00'" == NaiveTime::from_hms(0,0,0), being the offending line. What is the expected behavior here?

@leeola leeola changed the title Cannot deserialize time::Time and chrono::NaiveTime with MariaDB 10.3.18? Cannot deserialize 00:00:00 from MariaDB into time::Time and chrono::NaiveTime Jun 17, 2020
@leeola leeola changed the title Cannot deserialize 00:00:00 from MariaDB into time::Time and chrono::NaiveTime Cannot deserialize 00:00:00 from MariaDB into time::Time and chrono::NaiveTime Jun 17, 2020
@leeola
Copy link
Author

leeola commented Jun 17, 2020

The culprit does seem to be these 00:00:00 times. In my application, if I select rows with 02:00:00 for example, they successfully deserialize into a chrono::NaiveTime.

@blackwolf12333
Copy link
Contributor

I was looking at a similar problem with zero dates panicking on decode in #376, I can see if I can fix this too.

@blackwolf12333
Copy link
Contributor

blackwolf12333 commented Jun 28, 2020

I'm actually sort of surprised this crashes on MariaDB, according to their docs this should have worked. The docs about the encoding differ from the docs on MySQL, which does say something about times with all 0. I'm implementing a fix in #460 because the DATETIME thing is a bit harder to solve because 0000-00-00 is actually an invalid value for dates so chrono doesn't like that.

blackwolf12333 added a commit to blackwolf12333/sqlx that referenced this issue Jun 28, 2020
blackwolf12333 added a commit to blackwolf12333/sqlx that referenced this issue Jun 28, 2020
blackwolf12333 added a commit to blackwolf12333/sqlx that referenced this issue Jun 28, 2020
mehcode pushed a commit that referenced this issue Jun 29, 2020
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

Successfully merging a pull request may close this issue.

2 participants