Re: [boost] MySQL ASIO library

-----Original Message----- From: Boost On Behalf Of Ruben Perez via Boost Sent: 3 April 2020 19:09 To: boost@lists.boost.org Cc: Ruben Perez Subject: Re: [boost] MySQL ASIO library

Hi all,

I would like to re-take the discussion line about the MySQL library against

support-all-SQL library approach. As you all know, the current MySQL-Asio

only supports MySQL, following the approach of "doing a single thing and doing it right". As I already mentioned, I see this as a building block that a higher-level library can use, or as a directly usable library if you just need MySQL.

However, I know some of you were concerned about the potential difficulty in integrating different libraries like MySQL-Asio, in terms of complexity and efficiency. I have been looking into another SQL database protocol (concretely PostgreSQL, as it's the one I know the most after MySQL). In this mail I want to compare the two protocols from a high level perspective, and focus on the possible trouble that a higher-level SQL library could encounter when integrating MySQL-Asio with its equivalent for PostgreSQL (please note that the library for PostgreSQL does NOT exist yet).

- Both protocols start with a handshake. Most of the handshake parameters (credentials, schema to use...) are common, but some may be database-specific (e.g. collation to use for MySQL). I don't see much problem creating a wrapper with the minimum set of parameters for all backends in the higher-level

- Both protocols support a "query single" operation, where a SQL text string is sent to the server and a resultset is sent back (more on resultsets later). - Both protocols support prepared statements, where you send a statement to be prepared, as a text string, and something representing the prepared statement is returned. This prepared statement may then be executed as many times as required, returning a resultset each time. For PostgreSQL, the execution model is more granular than in MySQL (i.e. in MySQL there would be a single execute() call, in PostgreSQL there would be a bind(), an execute() and a sync(), the result of these three being a resultset). The higher-level library expose the minimum subset of steps. Again, I think it can be done without too many problems. - When a resultset is returned, both protocols send each individual row in a separate message. This is something I use in MySQL-Asio to allow single-row retrieval and could be implemented for PostgreSQL similarly. - When a resultset is returned, both protocols return some metadata describing the columns the resultset is made of. This is a little bit more heterogeneous, but there is common stuff (field name, field type...). Again, I see feasible that a high-level library exposes the common subset of metadata. - In MySQL-Asio, values are represented as a variant of all the types supported by the database. MySQL-Asio exposes all types supported by MySQL. Some of them are SQL standard and other are extensions. I guess the higher-level library should only expose the SQL standard types, and thus a mapping is required here. MySQL-Asio tries to make things as efficient as possible and avoids copying as much as possible. All used types are either ints/floats, datetimes (from the date library and chrono), or string_view's. Concretely, strings are not copied, but

original message is kept alive instead. With all this, I think a reasonably efficient mapping could be implemented by a higher-level library.

I hope this analysis may help convince those of you still in doubt. Any

As someone who suggested that this sort of analysis would help the cast for this proposed library, I sense that this is a considered and convincing argument that this library is extensible to other databases than MySQL. (But sadly I am not an expert on databases to know if the case will convince those much more knowledgeable). Of course, the 'proof of the pudding is in the eating' so a working link to another database would be much more persuasive, but I can understand the author reluctance to do this. So I would not discourage the author for continuing to prepare his library for Boost, but warn that it is a rocky road ahead for acceptance for any library proposal. But I can't see how there can't be users for it. Good luck. Paul the library library. the thoughts or

suggestions are welcome.

Regards, Ruben.

On Wed, 4 Mar 2020 at 16:07, Paul A Bristow via Boost wrote:

...

...

-----Original Message----- From: Boost On Behalf Of Richard Hodges via Boost Sent: 4 March 2020 13:46 To: boost@lists.boost.org List Cc: Richard Hodges Subject: Re: [boost] MySQL ASIO library

...

I'm not sure about Boost.MPI, but I thought it was not a wrapper of a single library, but of a standard API that can be implemented by different libraries. Boost.Regex is not a wrapper at all; it implements regular expressions from scratch. asio::ssl is not a library but a plugin for Boost.ASIO that provides one small piece of functionality compared to the rest of the library. Boost.Python is probably closest to an exception, although it is a binding to another language (not a library), which arguably only has one C API and implementation. Yes, there is CPython, but I don't believe it offers a C API.

This line of discussion between us is now moot. The author has confirmed that the implementation of the mysql protocol is original work.

I don't think the amount of contributions by itself is the goal. There

...

has to be value associated with the contribution. I just don't think a C++ wrapper of a specific library has enough value.

I for one have needed a good async mysql database layer on two occasions in production systems.

The first time I wrote a minimal wrapper around the c mysql libs (the c++ one is awful).

The second time I used amy, which is not fully asio compliant (it doesn't support coroutines or futures).

As a user of boost for over ten years, I would have benefitted greatly from a library like this being in boost.

I am not alone.

Talking to MySQL is a fundamental operation in the web world, which represents a huge chunk of programming effort.

It seems a no-brainer to me that a well maintained means of efficiently doing so would be a positive addition to boost.

By itself, this is a reasonably convincing case, but what would quiet some of doubters would be to have at least an outline of connecting to another database. Showing reasonable confidence that extension to other databases is feasible would be a big plus IMO.

Paul

_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost