Explore the possibility of making row copyable and drop owning_row.

The library is designed to support C++11. Make the CIs run the tests for older compiler versions:

• gcc 4.9 to current
• clang 3.3 to current
• Visual Studio 2017 to current

CIs should explicitly use a certain toolchain instead of relying on the platform default, which may change over time.

Provide an iterator type that allows iterating over a resultset (only for sync ops).

Investigate what retry strategies does the MySQL C driver offer and consider implementing them here.

Currently, only a header-only variant of the library is provided. Add a separate compilation option to reduce build times.

Currently, value::get throws boost::variant2::bad_variant_access. Is this correct?

Create a mock stream type that allows us to inject bytes written so we can write unit tests to test error cases.

Currently, fields having BIT type are returned as binary blobs. Provide an ad-hoc type in C++ to make working with BIT types easier.

When issuing a text query, the server immediately sends all rows to the client. This is not avoidable.
However, there is a mechanism in the protocol to prevent this in binary resultsets. Make use of this feature so the user can decide whether to fetch immediately all the rows or fetch them progressively.

I looking to test this library, perhaps contribute to it and petition the Boost community for adoption.

I am testing on Fedora 31. This distro substitutes MariaDB for MySQL.

I have encountered two problems:

1. The setup script syntax is not understood by MariaDB. I had to change it to use the older syntax:

-- User
DROP USER IF EXISTS example_user;
CREATE USER example_user IDENTIFIED BY 'example_password';
GRANT ALL PRIVILEGES ON mysql_asio_examples.* TO 'example_user'@`%`;
FLUSH PRIVILEGES;

2. After this, authentication fails in the example programs:

Error: Access denied for user 'example_user'@'%' to database 'mysql_native_password': dbaccess_denied_error, error code: mysql:1044

I am wondering whether the library needs to check database versions during the handshake and act accordingly? (I am not an expert in the MySQL protocol)

Add a comment to state the differences with these two libraries.

From the Boost review:

• Add a performance page in the documentation comparing the library with these two.
• Add a comparison to other C asynchronous APIs, in terms of ease of use.
• Clarify that the network protocol we're using here is stable.

Currently, channel performs 2 read operations per packet. Add some buffering strategy, as Boost.Beast does, so we can perform fewer read calls.

Currently, the TLS certificate is not validated, and no option is given to do so. Provide a way to customize the ssl::context that is internally created so TLS certificate validation is possible.

error_code ec (boost::mysql::errc::xxxx) should compile.

Provide a helper functions to make these cases easier:

• A query returning a single value, e.g. a SELECT COUNT(*) statement.
• A query returning an empty resultset, e.g. INSERT or DELETE.
• A single row.
• Zero or one rows.
• A single column.

Support MySQL protocol's compression feature.

Current implementation does not support specifying several queries in a single connection::query(), as this returns multiple resultsets. Support this by adding a mechanism to retrieve several resultsets from a single query.
Support prepared statements with OUT parameter binding (may also employ this mechanism).

Hi @anarthal Ruben,

great work, thanks!

There's quite a big community using asio in stand-alone mode without boost. Is boost really needed or would it be possible to make a definition to support compiling without the boost framework and namespaces?

i.e.

#ifdef ASIO_STANDALONE
#define MYSQL_COMPLETION_TOKEN ASIO_COMPLETION_TOKEN_FOR
#else 
#define MYSQL_COMPLETION_TOKEN BOOST_ASIO_COMPLETION_TOKEN_FOR
#endif

Thanks and best,
Roman

Update: according to grep, there's just a few includes from boost that are non-asio related, and their functionalities are covered since c++11 by std::*, except - ok - lexical cast, config and endian conversion:

#> egrep -Riohw "#include <boost/.*>"|sort|uniq | grep -v 'boost/asio'
#include <boost/config.hpp>
#include <boost/endian/conversion.hpp>
#include <boost/lexical_cast/try_lexical_convert.hpp>
#include <boost/optional/optional.hpp>
#include <boost/system/error_code.hpp>
#include <boost/system/system_error.hpp>
#include <boost/utility/string_view.hpp>
#include <boost/variant2/variant.hpp>

Coverage for an issue (already fixed) that would cause UB:

• Resultset containing rows is read using fetch_many/fetch_all
• OK packet contains an info string
• resultset::info accessed deallocated memory

Support row::operator[](string_view name) by adding references to metadata objects in rows.

Hi.
I'd like to know if it's possible to create prepared statements dynamically, for example by taking values from an external JSON files.

My problem is that make_values creates a std::array which size is fixed on the number of the make_values parameters, so it seems not possible to add values in runtime...

Is there a solution, please?

Thank you.

Support standard relational operators and std::hash so it can be used in ordered and unordered STL containers.

Ensure you can reconnect after a failed handshake/successful close.

Provide a mechanism to create a connection pool to re-use existing connections.

"START TRANSACTION" 、 "COMMIT" and "ROLLBACK" . Can I execute these statements with async_query() ?

Eventually, you will want an install target for this library.

My concern is that the include path include/mysql is already occupied by the offical mysql-c-connector and mariadb packages on linux systems. This will cause an include path conflict if this library ends up being installed on a linux system (likely!)

My suggestion would be to either name the include directory something like mysql-asio or in anticipation of pushing for boost acceptance, boost/mysql or boost/mysql-asio.

After resolving a host, it gets several endpoints with boost::asio::ip::tcp::resolver::results_type. How to make boost::mysql::tcp_connection connect to them?

Provide a way to configure timeouts for the network operations. Consider whether to make it a connection-wide option or a per-operation option.

Should be achievable using Asio's new cancellation slot mechanism. We should check how to leave connections in a well-defined state after cancellation (e.g. discarding any non-read frames before the next read).

Use sanitizers in CI builds.

Automate documentation generation

Verify that we handle correctly the case where TLS is not available and we pass in ssl_mode::enable.

Verify that we handle correctly the case where the server does not have the required capabilities.

Docca does not support quickbook in Doxygen comments, which Boost.Mysql uses. ATM we workaround the issue by monkey-patching a file in docca to prevent it from escaping quickbook. Decide and act on what to do with this.

I noticed that some async initiating functions had an optional argument after the completion token.

This is something you might want to revisit. The reason is that asio's direction is around auto-selecting the completion token based on the associated executor type of the io_object.

This means that the completion token becomes an optional argument. This argues for all other arguments coming prior.

This may mean a minor inconvenience in terms of having to offer 2 forms of initiating functions, one with the optional arg and one without. But the benefit is a more standardised interface and compatibility with asio/beast.

e.g. notice the DEFAULT template type and final argument:

https://www.boost.org/doc/libs/1_73_0/doc/html/boost_asio/reference/async_read/overload1.html

https://www.boost.org/doc/libs/1_73_0/doc/html/boost_asio/reference/asynchronous_operations.html#boost_asio.reference.asynchronous_operations.default_completion_tokens

Default completion tokens
Every I/O executor type has an associated default completion token type. This is specified via the default_completion_token trait. This trait may be used in asynchronous operation declarations as follows:

template <
    typename IoObject,
    typename CompletionToken =
      typename default_completion_token<
        typename IoObject::executor_type
      >::type
  >
auto async_xyz(
    IoObject& io_object,
    CompletionToken&& token =
      typename default_completion_token<
        typename IoObject::executor_type
      >::type{}
  );
If not specialised, this trait type is void, meaning no default completion token type is available for the given I/O executor.

[Example: The default_completion_token trait is specialised for the use_awaitable completion token so that it may be used as shown in the following example:

auto socket = use_awaitable.as_default_on(tcp::socket(my_context));
// ...
co_await socket.async_connect(my_endpoint); // Defaults to use_awaitable.

Add support for the authentication method sha256_password.

Verify that we handle correctly the case where the default auth plugin selected by the server is:

• The same as the one we selected.
• Different than the one we selected.
• One we do not support (currently unsupported).

Currently, starting a request to the server (e.g. query, prepare_statement, prepared_statement::execute) before fully reading a resultset results in undefined behavior. Check if there is any way of lifting this restriction (e.g. using packet sequence number) or provide a way to completely read and discard all remaining packets in a resultset.