Re: Review of Boost.MySQL

From: Christian Mazakas (christian.mazakas_at_[hidden])
Date: 2022-05-20 15:35:48

> They add an option to automatically reconnect the client when calling
ping()
> (and any other function). That could be interesting but again, I don't
think
> it's a common Asio pattern.

You know what's interesting, I've written something like this in the past
for
Asio.

Namely, I had a serial port connection class that would automatically
reconnect
every time the user invoked `.send_cmd(...)` on it. In practice, this
seemed to
work well.

I also implemented a similar design using Beast's websocket class. I
created a
`websocket_connection` class that would automatically reconnect and buffer
messages for users, sending them properly and then invoking a callback.

As useful as these were, I agree that they're not typical Asio-friendly
library
components. Instead, they're more user-friendly which is explicitly
exclusive
with Asio-friendliness.

> I'd say an example on reconnection would be nice, and raised
> https://github.com/anarthal/mysql/issues/92 to address it.

Indeed! Seems good enough to me.

I'm thinking there might be a couple of possible examples to write for users
here. There's an example for when the user is using Asio as their primary
runtime and everything is coded against it. The other is for a user who's
looking for either a blocking client or a client that's async and invokes a
callback perhaps of the form `std::function<...>`.

> To these ones:
>     connection::execute_statement(const prepared_statement&, const
>     params<ValueIterator>&)
>     connection::close_statement(const prepared_statement&)
>     connection::read_row(resultset&, row&)
> Do you think this interface would still be intuitive for the user?

Hmm, I can't speak to the intuition of other users but in my opinion, this
makes
Boost.MySQL closer to how Beast does things which I think is great.

I guess it really doesn't make sense conceptually for these things to be I/O
objects even though I understand why they are from an implementation
perspective.

These refactors would be great.

> https://github.com/anarthal/mysql/issues/85 tracks it, proposed names are
> field (for owning values) and field_view (for non-owning ones).

These sound great to me.

A lot of these changes sound really good. I'd be excited if they land.

- Christian