It seems to me that what you have *could* be a genuinely easy-to-use library with a relatively small amount of extra work. Specifically, if you were to hide the initial ASIO boilerplate then synchronous queries could be quite concise and require no ASIO knowledge.
This is a big war, as then you have thousands of ASIO users who find the usual pattern convincing, and they would complain about something similar. It may be worth sharing your thoughts to Chris, Asio's author, so that all Asio based libraries follow the same approach.
It's a mistake to keep an IP address for too long; you should re-resolve the hostname based on the time-to-live. Consider the case where the server has failover DNS or load balancing. Does the ASIO resolver cache based on the TTL? If it does, those calls should be cheap.
May be worth considering, raised https://github.com/anarthal/mysql/issues/86 to track it.
In libpq, I normally pass "service=foo" as the connection parameter string and it looks that up in pg_service.conf. I think that can specify a password. It also supports a ~/.pgpass file.
The AWS SDK for DynamoDB looks for credentials in a ~/.something file.
I think this varies a lot depending on the deployment strategy you're using. If you're using kubernetes, you have several options, too. I don't think it is the job of this library to try to accommodate every single possible deployment strategy the user may think of.
Make operator() an alias for execute().
It would be good if it could also be used in the coroutine case, i.e. if my connection_type is based on a coro_executor_type then maybe operator() could be an alias for async_execute:
statement.execute("a", 42, "c"); statement("a", 42, "c"); I honestly don't see a meaningful difference between these two.
I'm far from an expert, but you should be able to write code something like:
auto result = co_await query(params); for co_await (auto&& row: result) { ... }
auto t = co_await Transaction(conn);
AFAIK you can't co_await constructors, destructors, nor there is a Python's async for equivalent yet. So this API is restricted to sync ops.
I suggest mark the connection as broken but otherwise ignore the error.
So subsequent operations fail with a certain error code?
MySQL treats NUMERIC and DECIMAL the same, as exact numeric types. What C++ type would you put this into? float and double are not exact so they're not fit.
Provide a mechanism that allows the users to indicate what type they want to convert them to.
Could you please elaborate? Regards, Ruben.