Re: Proposing a MySQL client library for inclusion in Boost

From: Ruben Perez (rubenperez038_at_[hidden])
Date: 2022-04-02 07:33:29

On Sat, 2 Apr 2022, 00:23 Peter Dimov, <pdimov_at_[hidden]> wrote:

> 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?
>

It is. Does Describe provide any concept check (like
is_describable_class_v<T>)?

I would still implement these on top of the row parser I described in my
previous email.

I think these are all very useful features, and the library's direction
goes towards there, but feel they may be nice-to-haves at this particular
point in time. I would say the current variant interface is not perfect but
covers a decent amount of use cases. This new custom row parsing mechanism
can be introduced without breaking the current interface.

> (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>.
>

Granted, same point here.

>
>
>
>