Re: Proposing a MySQL client library for inclusion in Boost

From: Peter Dimov (pdimov_at_[hidden])
Date: 2022-04-01 22:23:40

Ruben Perez wrote:
...
> > >>> - Your value class is a variant behind the scenes i.e.
> > >>>
> > >>>   boost::variant2::variant<null_t, std::int64_t, std::uint64_t,
> > >>> boost::string_view, float, double, date, datetime, time>;
...
> You're assuming MySQL sends everything as strings that can be trivially
> parsed, but that's not the case. There are two different encodings, depending
> on whether a row came from connection::query or
> prepared_statement::execute (text queries employ a plain-text format, while
> prepared statements use binary encoding).
> In particular,
> the types DATE, DATETIME, TIME and BIT employ a nasty struct-like format in
> the binary protocol. BIT employs a binary-inside-text representation in the text
> protocol. DATE, TIME and DATETIME have the concept of "zero dates", which
> are invalid values MySQL allows but that don't represent any actual value.
> NULL values are represented as a bitmap in the binary protocol, and as special
> values in the text protocol.
> 
> I would expect a MySQL library to handle all these details (I would say this is
> one of the main benefits this library grants the user). As a user, I wouldn't
> want to know all this stuff.

Right.

But, if I have, say

struct X
{
    int64_t x;
    string y;
};

BOOST_DESCRIBE_STRUCT(X, (), (x, y))

and a matching result schema, isn't it reasonable to make `read_row` work for X?

(Values that can be null would use boost::optional or std::optional as members.)

I suppose the same applies to std::tuple<int64_t, string>.