Boost logo

Boost :

From: Ruben Perez (rubenperez038_at_[hidden])
Date: 2022-04-07 09:18:55


On Wed, 6 Apr 2022 at 14:58, Norvald H. Ryeng via Boost <
boost_at_[hidden]> wrote:

> On 30.03.2022 23:00, Ruben Perez via Boost wrote:
> > Hi all,
> >
> > I would like to propose my MySQL client library for inclusion in Boost.
> The
> > library features asynchronous communication with MySQL and MariaDB
> servers,
> > allowing the user to use txt queries and prepared statements. The library
> > is based on Boost.Asio and follows its asynchronous model (in a similar
> way
> > Boost.Beast does).
> >
> > The library is specific to MySQL and MariaDB systems, and is not intended
> > as a SQL framework or ORM. It fits use cases like HTTP servers (possibly
> > already using Beast), ETL pipelines or any other application that needs
> to
> > access a MySQL database and wants to benefit from Asio's asynchrony.
> >
> > Please note that the library is a full implementation of MySQL wire
> > protocol and does not use libmysqlclient under the hood.
>
> Great work!
>

Thanks :)

>
> Although MariaDB is a fork of MySQL and still to a large degree is
> compatible, at least in the simple and most common cases, both DBMSs are
> adding features independently and are diverging more and more.
>
> I work at MySQL Engineering at Oracle, and I've seen other attempts to
> treat MySQL and MariaDB as two variations of the same product, e.g., in
> packaging in Linux distros and client applications. As the DBMSs diverge
> more and more, these attempts usually fail, and the DBMSs have to be
> treated as two completely different DBMSs, like MySQL and Postgres.
>

I think your knowledge would be invaluable during the formal
library review. If you have the time and the energy, we would
all appreciate leaving your review, when the time comes.

>
> AFAIK, the basic protocol is still the same in both DBMSs, but new
> extensions are implemented in one and not the other, and there is no
> guarantee that they will remain compatible. I wouldn't be surprised if
> there are already subtle protocol differences when enabling some of the
> most recent extensions.
>

> I believe that in the long term the protocols will diverge more. Is the
> library designed in a way that can handle growing differences, and maybe
> a complete protocol incompatibility, in the future?
>

At this point in time, the library treats both systems the same. There are,
however, the following measures in place:

* In addition to unit tests, the library has a large set of
integration tests, which run against
real MySQL and MariaDB systems, in an attempt to catch such
differences as soon as possible. I have caught a couple of these
minor differences in the past, but was able to solve them in
a way that made both DBMS happy (there was something MySQL accepted
and MariaDB didn't).

* These tests are run in CIs, which do differentiate between them (e.g.
run SHA256 auth tests for MySQL 8.x but not for MariaDB or MySQL 5.x).
The connection object stores a state object, holding stuff like the
server capabilities, which are set after the initial handshake. These
capabilities
are then passed to the individual operations, to handle any possible
difference
between servers that may be expressed in terms of server capabilities.

A couple questions:

* Which kind of protocol incompatibilities would you think would be possible
in the future? Are we talking about minor differences (like different auth
plugins,
and things that can be expressed in terms of server capabilities)? Or are
we talking about a complete redesign of the MySQL protocol?
* Is there any place in the documentation where I could read about these
new additions we are talking about?
* Do you think anyone else in MySQL server team would be interested in
participating in the formal review for this library? I think their help
would
be much appreciated.

Cheers,
Ruben.

>
> Best regards,
>
> Norvald
>
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost
>


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk