`bit(1)` column cannot parse it into `bool`

[StrikeW]

Hi @blackbeam, I have a bit(1) column in mysql and I cannot parse it into bool. I find that the code matches [b'0'] and [b'1']. I am curious that why need to match char '0' and '1' instead of byte 0x0 and 0x1 here? Why not also add patterns to match [0] and [1]?
version: mysql_common-0.31.0

related: #3

[blackbeam]

Hi.

The only valid BOOLEN encodings are either integer 0 or 1 (for the binary protocol) or string '0' or '1' (for the text protocol). Even though bit(1) may be treated as a non-canonical form of a boolean value I'm against the idea of introducing an implicit coercion. This seem more natural because Rust tends towards being explicit rather than implicit.

BTW, why are you using bit(1) instead of just boolean?

[StrikeW]

So your point is that the MySQL bit data type should be only mapped to Vec<u8> in Rust, am I get you right?

BTW, why are you using bit(1) instead of just boolean?

Our user may have this use case, and we are ingesting their table into our system.

[blackbeam]

So your point is that the MySQL bit data type should be only mapped to Vec in Rust, am I get you right?

No. My point is that generic MySql driver is not a place for any kind of special treatment as the one suggested here. Another instance of this kind of special treatment would be to also parse strings true and false as bool. This might seem different, but this is because of external cultural reasons -from just the MySql driver perspective both these treatments are of the same nature.

Our user may have this use case, and we are ingesting their table into our system.

Oh, I see. Then this starts to look odd to me. I mean that the meaning of the schema is defined by some external entity (your user) and you, for some reasons, comes to a conclusion that bit(1) means bool, but I don't see why this is the case. Another possibility could be that bit(1) here just because the external system is still evolving and it is planned for the schema to migrate to bit(2) or bit(whatever) in the nearest future.
From this perspective only reasonable options I see are:

1. (lazy way) Encode the field as an array [u8; N] where N properly matches n in the corresponding bit(n).
2. (best option) Introduce the proper bitflags type (say using the bitflags crate) with corresponding FromValue and Into<Value> implementations.

If you, for whatever reason, want to have this kind of special treatment then nothing stops you from implementing it yourself. It is always possible to define a newtype with conversions that fits your needs.

[tonyhook]

Hi guys, I just want to explain why there's BIT(1) in MySQL.
When someone uses Spring Boot for backend development, Spring Boot Data generates MySQL table with BIT(1) for Boolean field of a class decorated with @entity.
If the Java project and the Rust project exchange data through MySQL, the Rust side may meet Bytes("\u{1}") and panic.

Couldn't convert Row { enabled: Bytes("\u{1}") } to type (bool). (see FromRow documentation)

[tonyhook]

The following code works for me.

        let students = conn.query_map(
            "SELECT id, enabled FROM student",
            | raw: (i32, String)
            | -> Student {Student {
                id: raw.0,
                enabled: raw.1.as_bytes()[0] > 0,
            }}
        ).unwrap();