Re: [boost] Proposing a MySQL client library for inclusion in Boost

2 Apr 2022

      On Sat, 2 Apr 2022, 00:23 Peter Dimov,  wrote:
...
...
...
...
...
...
- Your value class is a variant behind the scenes i.e.
boost::variant2::variant;
...
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
...
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
Ruben Perez wrote:
...
the text
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.
Granted, same point here.
...