Boost logo

Boost :

From: Mateusz Loskot (mateusz_at_[hidden])
Date: 2020-03-04 12:12:19


On Wed, 4 Mar 2020 at 10:31, Joseph Van Riper via Boost
<boost_at_[hidden]> wrote:
> On Tue, Mar 3, 2020 at 8:50 PM Ruben Perez via Boost <boost_at_[hidden]> wrote:
> >
> > I have been writing an ASIO-based client for MySQL, trying to mimic what
> > Beast is to HTTP. It currently supports SQL queries and prepared
> > statements. It can be viewed here:
> >
> > https://github.com/anarthal/mysql-asio
> >
> > Do you guys think this has the potential to be useful or become part of
> > Boost long term? Any feedback is very welcome.
> >
>
> Why just MySQL?
>
> I would take more interest in a library capable of supporting many database
> engines. Or, if not such a variety, at least target ODBC, as you can reach
> more engines through ODBC drivers.
> [...]
> For a boost library, I would hope it would not limit the developer to a single engine.
>
> This said, it would be interesting to see some sort of library become part
> of the standard library, and boost offers a track towards standardization.
> SQL databases are a time tested way to work with data, and I would
> certainly use a boost library capable of supporting the engines I use.

FYI, the RDB library is not a new topic on this list.
Since I've just got a large Americano, I will dig the archives below :)

It's more than a decade old with first proposals arriving in 2004
https://lists.boost.org/Archives/boost//2004/10/74169.php

During BoostCon 2009, the Library in Week initiative brainstormed
the idea of std::rdb where number of Boost community members
participated, see at the bottom of this page
https://github.com/boostcon/2009_presentations
There used to be a mailing list for std::rdb
http://mail-lists.crystalclearsoftware.com/listinfo.cgi/std_rdb-crystalclearsoftware.com

In Sept 2009, Jean-Louis Leroy started arriving with some code for std::rdb,
see number of threads:
https://lists.boost.org/Archives/boost//2009/09/index.php

As https://github.com/soci/soci library with its unique,
as for C+98/03, approach by Maciej Sobczak gained some
attention, it had been discussed in the context of std::rdb
and Boost number of times

In 2010, Roland Bock resurrected the topic
https://lists.boost.org/Archives/boost//2010/09/170947.php
and arrived with a very interesting approach for C++11
https://github.com/rbock/sqlpp11
As long time maintainer of the SOCI library, I had also discussed
possibilities to combine both approaches, run-time
and compile-time binding, there are some posts in the archives.
Roland presented sqlcpp11 on number of conferences in 2014
and 2015, you can find it on youtube.
There is also https://github.com/rbock/sqlpp117

Another longish iteration of RDB discussions happened around 2013
when Thomas Neumann proposed DBI paper:
https://isocpp.org/blog/2013/03/new-paper-n3612-desiderata-of-a-c11-database-interface-thomas-neumann
and C++ ISO discussion groups on databases started
https://groups.google.com/a/isocpp.org/forum/#!forum/databases

Each time the topic re-appeared, discussions were long and detailed,
but far from any consensus and authors would drop the idea of
submitting their libraries to Boost review. If you remember
CMake for/in Boost debates, the RDB had lots in common :)

I had been a maintainer of SOCI, a database abstraction library with
support for DB2, Firebird, MySQL, Oracle, ODBC, PostgreSQL, SQLite
for more than 10 years.

Development of such a library is very time consuming, and long-term
maintenance is even more time consuming, and often turns into a frustrating
and thankless job full of DevOps hurdles, a job impossible to perform well
without *multiple* *active* team members with DB backend specific exercise.
(e.g. ad-hoc contributors submitting GitHub PRs become eventually
more problematic than helpful).

Finally, everyone has an opinion on how to get it right.
It's just far from being as attractive as a year long gig to
get a compact utility into Boost.

Best regards,

-- 
Mateusz Loskot, http://mateusz.loskot.net

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