Re: Review of Boost.MySql

From: Ruben Perez (rubenperez038_at_[hidden])
Date: 2022-05-13 13:14:39

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

Hi Phil, please accept my apologies for the misunderstanding.
I still think much of your comments were useful and many
will end as improvements in the library.

>
> 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?

Ease of use is written there because it is really important to me.
I've tried to hide as many complexities of the protocol as I've been
able to, without compromising performance (maybe too many for
a protocol library, as we'll discuss below). I've abstracted the handshake
algorithm, the different encodings, and tried to expose an interface
as simple as possible. But the library is not an ORM or a SQL framework,
and the documentation may not be clear enough in scope.
https://github.com/anarthal/mysql/issues/70 addresses this rewording.

>
> 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.

I've raised https://github.com/anarthal/mysql/issues/76 to correct
that wording, as it is definitely not true. This section should explain
the whole story, with both the library limitation and the protocol capabilities.
I've raised https://github.com/anarthal/mysql/issues/75 for pipeline mode.

Regards,
Ruben.