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.
But, if I have, say
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>.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk