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_rea... The handler signature for this operation is void(boost::mysql::error_code, std::vectorboost::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_qu... 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_optio... https://anarthal.github.io/mysql/mysql/ref/boost__mysql__value/get_optional....
Sounds also unusual to have two member functions for the different versions of optional. Regards, Marcelo