From: Marcelo Zimbres Silva (mzimbres_at_[hidden])
Date: 2022-03-31 16:00:34
Hi Ruben,
I have had a look into your library and some questions arise
> https://anarthal.github.io/mysql/mysql/ref/boost__mysql__resultset/async_read_all.html
> The handler signature for this operation is void(boost::mysql::error_code, std::vector<boost::mysql::row>).
> etc.
Having a std::vector in the signature of the completion handler is
unusual in ASIO. In general large objects should be passed as
parameters in the async operation e.g. socket::async_read gets a
dynamic_buffer which is a lightweight view to storage.
Additionally, there is not support for custom allocators. That
wouldn't be a big problem to me if I could reuse the same memory for
each request but the interface above prevents me from doing so.
> https://anarthal.github.io/mysql/mysql/ref/boost__mysql__connection/async_query/overload1.html
> The handler signature for this operation is void(boost::mysql::error_code, boost::mysql::resultset<Stream>)
Hier the completion handler is returning an io object i.e.
boost::mysql::resultset, which is also unusual as far as I can see.
Does that play nice with executors? I would prefer having the
completion handler return config parameters with which I can
instantiate a boost::mysql::resultset myself in my desired executor.
> https://anarthal.github.io/mysql/mysql/ref/boost__mysql__connection.html
I don't see a reason for this class, or at least I fail to see what
state does the mysql protocol imposes on you that would justify this
class. I would prefer free funcitions much more here, for example, in
the same way as beast::http::async_read.
> https://anarthal.github.io/mysql/mysql/ref/boost__mysql__value/get_std_optional.html
> https://anarthal.github.io/mysql/mysql/ref/boost__mysql__value/get_optional.html
Sounds also unusual to have two member functions for the different
versions of optional.
Regards,
Marcelo