Ruben Perez 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 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