Re: MySQL ASIO library

From: Ruben Perez (rubenperez038_at_[hidden])
Date: 2020-03-04 19:05:16

El mié., 4 mar. 2020 18:36, Richard Hodges via Boost <boost_at_[hidden]>
escribió:

> On Wed, 4 Mar 2020 at 17:48, Kostas Savvidis via Boost <
> boost_at_[hidden]> wrote:
>
> >
> >
> > > On Mar 4, 2020, at 16:24, Ruben Perez via Boost <boost_at_[hidden]
> >
> > 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
> hodges.r_at_[hidden]
> office: [phone]
> home: [phone]
> mobile: [phone]
>
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost
>