MySQL ASIO library

classic Classic list List threaded Threaded
42 messages Options
123
Reply | Threaded
Open this post in threaded view
|

MySQL ASIO library

Boost - Dev mailing list
Hi all,

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.

Thanks,
Ruben (Anarthal).

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: MySQL ASIO library

Boost - Dev mailing list
On Wed, 4 Mar 2020 at 02:50, Ruben Perez via Boost <[hidden email]>
wrote:

> Hi all,
>
> 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



Will definitely take a look. Such a thing is sorely needed imho.

<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.
>
> Thanks,
> Ruben (Anarthal).
>
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost
>
--
Richard Hodges
[hidden email]
office: +442032898513
home: +376841522
mobile: +376380212

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: MySQL ASIO library

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On Tue, Mar 3, 2020 at 8:50 PM Ruben Perez via Boost <[hidden email]>
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.

While I understand many people like MySQL, some use cases call for other
engines (like SQLite3, providing a lightweight, simple database file
without all the overhead of MySQL).  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.

To answer your questions directly... yes, it has the potential to be
useful, and perhaps part of boost on a longer term I think, but it should
not limit the developer to a single engine.  At a minimum, I should think
it ought to support ODBC.

(BTW, I think Howard Hinnant's date library, or something close to it, is
due for inclusion in the standard library soon... we sure as heck need
it... so if you aren't already doing so, you might want to track that and
support the use of the standard library version of this when it finally
comes out).

- Trey

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: MySQL ASIO library

Boost - Dev mailing list
On Wed, Mar 4, 2020 at 12:32 PM Joseph Van Riper via Boost
<[hidden email]> wrote:

>
> On Tue, Mar 3, 2020 at 8:50 PM Ruben Perez via Boost <[hidden email]>
> 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.
>
> While I understand many people like MySQL, some use cases call for other
> engines (like SQLite3, providing a lightweight, simple database file
> without all the overhead of MySQL).  For a boost library, I would hope it
> would not limit the developer to a single engine.

+1

I don't see the point of having a Boost wrapper for just one specific
backend. People who want that could just use MySQL C or C++ API
directly.

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: MySQL ASIO library

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
> Why just MySQL?

Getting something useful released is more important than getting something
perfect released.

If Ruben has a ready-to-go solution for MySQL, why not make it available to
users?

It can always be complemented or extended with Oracle, SQLite, ODBC etc etc
later.

If you try to release the all-encompassing-every-database-under-the-sun
solution in one hit, you'll just end up releasing nothing.

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: MySQL ASIO library

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On Wed, 4 Mar 2020 at 10:31, Joseph Van Riper via Boost
<[hidden email]> wrote:

> On Tue, Mar 3, 2020 at 8:50 PM Ruben Perez via Boost <[hidden email]> 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

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: MySQL ASIO library

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On Wed, Mar 4, 2020 at 1:50 PM Richard Hodges via Boost
<[hidden email]> wrote:
>
> > Why just MySQL?
>
> Getting something useful released is more important than getting something
> perfect released.
>
> If Ruben has a ready-to-go solution for MySQL, why not make it available to
> users?

Making it available to users is not the same as making it part of
Boost. Boost is known for general purpose libraries, as well as more
domain-focused solutions, but it is not a place for wrappers around
specific other libraries. Let alone, when the said libraries already
have C/C++ API.

> It can always be complemented or extended with Oracle, SQLite, ODBC etc etc
> later.

If the proposed library offers a stable and flexible API that can be
backed by multiple implementations then by all means - that would be a
very interesting proposal indeed. But the author has to demonstrate
that the proposed user API can in fact be supported by more than one
backend, so at least two backends need to be presented, and preferably
with guidelines and infrastructure for adding more.

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: MySQL ASIO library

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
El mié., 4 mar. 2020 10:18, Andrey Semashev via Boost <[hidden email]>
escribió:

> On Wed, Mar 4, 2020 at 12:32 PM Joseph Van Riper via Boost
> <[hidden email]> wrote:
> >
> > On Tue, Mar 3, 2020 at 8:50 PM Ruben Perez via Boost <
> [hidden email]>
> > 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.
> >
> > While I understand many people like MySQL, some use cases call for other
> > engines (like SQLite3, providing a lightweight, simple database file
> > without all the overhead of MySQL).  For a boost library, I would hope it
> > would not limit the developer to a single engine.
>
> +1
>
> I don't see the point of having a Boost wrapper for just one specific
> backend. People who want that could just use MySQL C or C++ API
> directly.
>

Just to clarify, this is *not* a wrapper around the MySQL C API, it is an
implementation of the MySQL protocol based in ASIO.

I see this as a building block, that can be used by any other bigger, more
abstract library providing multiple backends. This library takes the
approach of doing a single thing well. It provides no abstraction over
MySQL specifics. But it can be seen as a step towards something bigger.

The other value I see in this is that it is Asio-based. So it would
contribute towards the creation of an Asio-based ecosystem. The aim is to
integrate well with any project that uses Asio (e.g. using Beast), which I
don't think the MySQL C++ API gives you.


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

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: MySQL ASIO library

Boost - Dev mailing list
On Wed, Mar 4, 2020 at 5:18 AM Ruben Perez via Boost
<[hidden email]> wrote:
> Just to clarify, this is *not* a wrapper around the MySQL C API, it is an
> implementation of the MySQL protocol based in ASIO.

I took a quick look, and yes there's quite a bit of work here. It uses
the Asio asynchronous model idioms correctly.

Regards

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: MySQL ASIO library

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
[Sending this reply to list as opposed to personal email]

On Wed, Mar 4, 2020 at 3:39 PM Richard Hodges <[hidden email]> wrote:

> On Wed, 4 Mar 2020 at 13:25, Andrey Semashev <[hidden email]> wrote:
>>
>> On Wed, Mar 4, 2020 at 1:50 PM Richard Hodges via Boost
>> <[hidden email]> wrote:
>> >
>> > > Why just MySQL?
>> >
>> > Getting something useful released is more important than getting something
>> > perfect released.
>> >
>> > If Ruben has a ready-to-go solution for MySQL, why not make it available to
>> > users?
>>
>> Making it available to users is not the same as making it part of
>> Boost. Boost is known for general purpose libraries, as well as more
>> domain-focused solutions, but it is not a place for wrappers around
>> specific other libraries. Let alone, when the said libraries already
>> have C/C++ API.
>
> Boost also has mpi, regex, asio::ssl and python. What are these if not wrappers around common c libraries?

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.

>> > It can always be complemented or extended with Oracle, SQLite, ODBC etc etc
>> > later.
>>
>> If the proposed library offers a stable and flexible API that can be
>> backed by multiple implementations then by all means - that would be a
>> very interesting proposal indeed. But the author has to demonstrate
>> that the proposed user API can in fact be supported by more than one
>> backend, so at least two backends need to be presented, and preferably
>> with guidelines and infrastructure for adding more.
>
> Mpi, regex and python would dispute this arbitrary restriction.

I don't think so, as per above.

> Boost suffers from a lack of contribution. Is there any value in making contribution difficult?

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.

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: MySQL ASIO library

Boost - Dev mailing list
>
> 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.



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


--
Richard Hodges
[hidden email]
office: +442032898513
home: +376841522
mobile: +376380212

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: MySQL ASIO library

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
El mié., 4 mar. 2020 14:16, Andrey Semashev via Boost <[hidden email]>
escribió:

> [Sending this reply to list as opposed to personal email]
>
> On Wed, Mar 4, 2020 at 3:39 PM Richard Hodges <[hidden email]> wrote:
> > On Wed, 4 Mar 2020 at 13:25, Andrey Semashev <[hidden email]>
> wrote:
> >>
> >> On Wed, Mar 4, 2020 at 1:50 PM Richard Hodges via Boost
> >> <[hidden email]> wrote:
> >> >
> >> > > Why just MySQL?
> >> >
> >> > Getting something useful released is more important than getting
> something
> >> > perfect released.
> >> >
> >> > If Ruben has a ready-to-go solution for MySQL, why not make it
> available to
> >> > users?
> >>
> >> Making it available to users is not the same as making it part of
> >> Boost. Boost is known for general purpose libraries, as well as more
> >> domain-focused solutions, but it is not a place for wrappers around
> >> specific other libraries. Let alone, when the said libraries already
> >> have C/C++ API.
> >
> > Boost also has mpi, regex, asio::ssl and python. What are these if not
> wrappers around common c libraries?
>
> 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.
>
> >> > It can always be complemented or extended with Oracle, SQLite, ODBC
> etc etc
> >> > later.
> >>
> >> If the proposed library offers a stable and flexible API that can be
> >> backed by multiple implementations then by all means - that would be a
> >> very interesting proposal indeed. But the author has to demonstrate
> >> that the proposed user API can in fact be supported by more than one
> >> backend, so at least two backends need to be presented, and preferably
> >> with guidelines and infrastructure for adding more.
> >
> > Mpi, regex and python would dispute this arbitrary restriction.
>
> I don't think so, as per above.
>
> > Boost suffers from a lack of contribution. Is there any value in making
> contribution difficult?
>
> 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.
>

Just to clarify, this is *not* a wrapper around the MySQL C API, it is an
implementation of the MySQL protocol based in ASIO.


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

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: MySQL ASIO library

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On 2020-03-04 16:17, Ruben Perez via Boost wrote:

> El mié., 4 mar. 2020 10:18, Andrey Semashev via Boost <[hidden email]>
> escribió:
>
>> I don't see the point of having a Boost wrapper for just one specific
>> backend. People who want that could just use MySQL C or C++ API
>> directly.
>>
>
> Just to clarify, this is *not* a wrapper around the MySQL C API, it is an
> implementation of the MySQL protocol based in ASIO.
>
> I see this as a building block, that can be used by any other bigger, more
> abstract library providing multiple backends. This library takes the
> approach of doing a single thing well. It provides no abstraction over
> MySQL specifics. But it can be seen as a step towards something bigger.
>
> The other value I see in this is that it is Asio-based. So it would
> contribute towards the creation of an Asio-based ecosystem. The aim is to
> integrate well with any project that uses Asio (e.g. using Beast), which I
> don't think the MySQL C++ API gives you.

I see, thanks for clarifying.

A custom implementation of MySQL protocol could be useful to MySQL and
ASIO users, so there is value. But I'm still not quite sure it would be
universally useful. I mean, if I was implementing an application that
needs integration with an SQL database, I'm not sure I would have picked
your library over the other alternatives. I'd be more interested in a
universal API that allows me to plug in whatever SQL database engine I
need without having to rewrite my code. But that's just my wishful thinking.

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: MySQL ASIO library

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list


> -----Original Message-----
> From: Boost <[hidden email]> On Behalf Of Richard Hodges via
> Boost
> Sent: 4 March 2020 13:46
> To: [hidden email] List <[hidden email]>
> Cc: Richard Hodges <[hidden email]>
> 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
Reply | Threaded
Open this post in threaded view
|

Re: MySQL ASIO library

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list


> On Mar 4, 2020, at 16:24, Ruben Perez via Boost <[hidden email]> wrote:
>
> Just to clarify, this is *not* a wrapper around the MySQL C API, it is an
> implementation of the MySQL protocol based in ASIO.

I would like to know if your software also manages the network protocol complexities?
1) Can one can talk to a server over a unix pipe or only over IP network?
2) In all DBI systems I have seen,
example code starts with creating a connection object and then nobody explains to the
casual user like me what is supposed to happen if the connection to the database is to be maintained over hours or days. Does your library  manage this or are we still supposed to write all the connection checking and reconnection code manually?

Thanks,
Kostas

============================================================================================
Institute of Nuclear and Particle Physics
NCSR Demokritos
https://github.com/kotika/random <https://github.com/kotika/random>
https://mixmax.hepforge.org <https://mixmax.hepforge.org/>

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: MySQL ASIO library

Boost - Dev mailing list
On Wed, 4 Mar 2020 at 17:48, Kostas Savvidis via Boost <
[hidden email]> wrote:

>
>
> > On Mar 4, 2020, at 16:24, Ruben Perez via Boost <[hidden email]>
> wrote:
> >
> > Just to clarify, this is *not* a wrapper around the MySQL C API, it is an
> > implementation of the MySQL protocol based in ASIO.
>
> I would like to know if your software also manages the network protocol
> complexities?
> 1) Can one can talk to a server over a unix pipe or only over IP network?
>

From looking at the code, it seems that the MySQL protocol will work on any
asio stream type, including posix streams (pipes). Setting up the stream is
a (simple) Asio concern. The communication over that stream is a mysql
concern.



> 2) In all DBI systems I have seen,
> example code starts with creating a connection object and then nobody
> explains to the
> casual user like me what is supposed to happen if the connection to the
> database is to be maintained over hours or days. Does your library  manage
> this or are we still supposed to write all the connection checking and
> reconnection code manually?
>

Asio streams do not auto-reconnect. I would imagine that if you need this,
it would be logic you have to implement over the top of this library.

In practice, using the auto-reconnect feature of the mysql C library is
problematic for anything other than the simplest of operations. Reconnected
connections forget any state they contained.


>
> Thanks,
> Kostas
>
>
> ============================================================================================
> Institute of Nuclear and Particle Physics
> NCSR Demokritos
> https://github.com/kotika/random <https://github.com/kotika/random>
> https://mixmax.hepforge.org <https://mixmax.hepforge.org/>
>
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost
>


--
Richard Hodges
[hidden email]
office: +442032898513
home: +376841522
mobile: +376380212

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: MySQL ASIO library

Boost - Dev mailing list
El mié., 4 mar. 2020 18:36, Richard Hodges via Boost <[hidden email]>
escribió:

> On Wed, 4 Mar 2020 at 17:48, Kostas Savvidis via Boost <
> [hidden email]> wrote:
>
> >
> >
> > > On Mar 4, 2020, at 16:24, Ruben Perez via Boost <[hidden email]
> >
> > wrote:
> > >
> > > Just to clarify, this is *not* a wrapper around the MySQL C API, it is
> an
> > > implementation of the MySQL protocol based in ASIO.
> >
> > I would like to know if your software also manages the network protocol
> > complexities?
> > 1) Can one can talk to a server over a unix pipe or only over IP network?
> >
>
> From looking at the code, it seems that the MySQL protocol will work on any
> asio stream type, including posix streams (pipes). Setting up the stream is
> a (simple) Asio concern. The communication over that stream is a mysql
> concern.
>

That is correct. Anything being an Asio stream should just work. For TCP
sockets there are tests and some typedefs to make things easier. I have in
my TODO to add tests and typedefs for UNIX sockets and named pipes.


>
>
> > 2) In all DBI systems I have seen,
> > example code starts with creating a connection object and then nobody
> > explains to the
> > casual user like me what is supposed to happen if the connection to the
> > database is to be maintained over hours or days. Does your library
> manage
> > this or are we still supposed to write all the connection checking and
> > reconnection code manually?
> >
>
> Asio streams do not auto-reconnect. I would imagine that if you need this,
> it would be logic you have to implement over the top of this library.
>
> In practice, using the auto-reconnect feature of the mysql C library is
> problematic for anything other than the simplest of operations. Reconnected
> connections forget any state they contained.
>

Also true. At this point, if your stream has a communication error, you
will have to handle the reconnect yourself. I can add some notes about that
in the docs.

That can be a feature for the future. However I see that the handling may
depend too much on the application  (time between retries, algorithm to
compute retry time, max retries... Plus we would need a sort of a callback
system to perform things like logging). So I think it may be feasible but
not straightforward.


>
> >
> > Thanks,
> > Kostas
> >
> >
> >
> ============================================================================================
> > Institute of Nuclear and Particle Physics
> > NCSR Demokritos
> > https://github.com/kotika/random <https://github.com/kotika/random>
> > https://mixmax.hepforge.org <https://mixmax.hepforge.org/>
> >
> > _______________________________________________
> > Unsubscribe & other changes:
> > http://lists.boost.org/mailman/listinfo.cgi/boost
> >
>
>
> --
> Richard Hodges
> [hidden email]
> office: +442032898513
> home: +376841522
> mobile: +376380212
>
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost
>

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: MySQL ASIO library

Boost - Dev mailing list
A universal DB abstraction is definitely the ideal but it shouldn't halt
the acceptance of an existing library that integrates well with Boost.

MySQL is a common choice and many web/networking applications rely on it.
Beast + Asio + a MySQL wrapper in Boost makes C++ a competitive choice.

- Chris

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: MySQL ASIO library

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
Le mercredi 04 mars 2020 à 16:06 +0000, Paul A Bristow via Boost a
écrit :

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

I expect a more versatile db library to rely on underlying low-level
backends such as this one, so i tend to disagree here: trying to handle
multiple database here will greatly increase complexity with few
additional value for the user: differences in SQL dialects and
supported types, for example, will anyway prevent any simple backend
switch for the user.

Having a common shared design for the different backends, however, will
indeed be useful in building a higher level db abstraction, though (not
sure if it was your point).

Regards,

Julien


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: MySQL ASIO library

Boost - Dev mailing list
On 2020-03-05 10:02, Julien Blanc via Boost wrote:

> Le mercredi 04 mars 2020 à 16:06 +0000, Paul A Bristow via Boost a
> écrit :
>>>
>>> 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.
>
> I expect a more versatile db library to rely on underlying low-level
> backends such as this one, so i tend to disagree here: trying to handle
> multiple database here will greatly increase complexity with few
> additional value for the user: differences in SQL dialects and
> supported types, for example, will anyway prevent any simple backend
> switch for the user.
>
> Having a common shared design for the different backends, however, will
> indeed be useful in building a higher level db abstraction, though (not
> sure if it was your point).

Right. But when the backends are not part of a common solution, I have a
hard time seeing them have a compatible interface, which makes writing
the higher level unifying library more difficult and the end result less
efficient. Granted, you will have the same kind of problems when using
the native C APIs of database engines. But my point is that the solution
that is designed from the start as a unifying frontend + multiple
backends from the start has the potential of being more efficient and
more straightforward.

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