Re: Review of Boost.MySql

From: Phil Endecott (spam_from_boost_dev_at_[hidden])
Date: 2022-05-12 14:25:09

Hi Ruben,

Ruben Perez wrote:
> This library is supposed to be a protocol driver library, so it
> provides primitives close to the MySQL protocol.

It's frustrating to see this now, after writing my review.

I thought I was reviewing a library that, quoting your docs,
made "ease of use" its first design goal and aimed to "hide the
MySQL protocol complexities". Make up your mind, are you trying
to hide the protocol or provide something close to it?

And in a later message:

Ruben Perez wrote:
> When sending two queries
[...]
> You could also initiate the next query without completely reading 
> all the packets sent by the server.
[...]
> This is possible at the protocol level.
[...]
> This [...] is *currently not possible* with the current [library] interface.

Contrast that with what your docs say:

   Warning
   Because of how the MySQL protocol works, once you obtain a resultset,
   you must read it entirely (i.e. until it's complete) before engaging
   in any subsequent operation that implies communication with the server
   (e.g. issuing another query, preparing a statement, closing a
   statement...). Failing to do so results in undefined behavior.

You are explicitly blaming the protocol for this restriction in
that quote. It seems that that is not true, and that it is a
limitation of the library.

If I were writing my review again on the basis of this being a low-level
protocol library - which I'm not going to do, I don't have time - I would
probably say that support for this sort of pipelining is essential. I
would perhaps hope to see "low-level" functions that encode and decode
the protocol packets, which the user could even use with their own
networking layer, if they wanted to.

> Pipeline modes usually specify an option on what to do when a query 
> in the pipeline fails. Here, you don't have that - subsequent queries 
> will be executed regardless of the result of previous ones.

Transactions help here though. For example:

Transaction t(conn);
for (auto&& a: lots_of_things) {
   execute_insert_stmt(a);
}
t.commit();

I would expect pipelining to significantly improve the performance of
that, especially if there were significant network latency.

Regards, Phil.