On Wed, 18 May 2022 at 11:05, Kostas Savvidis
Hi Ruben,
Some people have already suggested making the tcp_ssl connection as the default. In that spirit, it seems to me that it would be better to remove such prefixes as tcp_ssl from tcp_ssl_prepared_statement and tcp_ssl_resultset and instead add apropriate prefixes to the non-default connections. Actually, since the only other type is unix socket, one only need to add the prefix plaintext or nonssl for the noncrypted connections.
I like how this sounds. I've updated https://github.com/anarthal/mysql/issues/73 to reflect your comments. Note that we may want to add named_pipe_connection for Windows in the future.
Moreover, is there no technical solution that can completely remove the need to deal with these distinct names for resultset and prepared_statement after the appropriate connection is established?
They depend on the Stream type because they have I/O operations. E.g. for a prepared_statement, you need the Stream type to implement the prepared_statement::execute function. Internally, these are really just pointers to the connection object (more or less). One possible option is making prepared_statement and resultset not be I/O objects, and move these functions to the connection object. So the following signatures: prepared_statement::execute(const params<ValueIterator>&) prepared_statement::close() resultset::read_one(row&) Would change to these ones: connection::execute_statement(const prepared_statement&, const params<ValueIterator>&) connection::close_statement(const prepared_statement&) connection::read_row(resultset&, row&) What do you think? Regards, Ruben.
On May 18, 2022, at 13:27, Ruben Perez via Boost
wrote: So the following signatures:
prepared_statement::execute(const params<ValueIterator>&) prepared_statement::close() resultset::read_one(row&)
Would change to these ones:
connection::execute_statement(const prepared_statement&, const params<ValueIterator>&) connection::close_statement(const prepared_statement&) connection::read_row(resultset&, row&)
What do you think?
Someone with experience using the library and a better understanding than myself should comment. But I noticed in the postgres-asio example you declare auto stmt = conn.prepare_statement("UPDATE mytable SET f1 = $1 WHERE f2 = $2"); In the mysql exaples you did not use auto, I presume this style is possible also in mysql, then maybe not worth changing signatures as it is not such a big deal. Cheers, Kostas
On May 18, 2022, at 13:27, Ruben Perez via Boost
mailto:boost@lists.boost.org> wrote: So the following signatures:
prepared_statement::execute(const params<ValueIterator>&) prepared_statement::close() resultset::read_one(row&)
Would change to these ones:
connection::execute_statement(const prepared_statement&, const params<ValueIterator>&) connection::close_statement(const prepared_statement&) connection::read_row(resultset&, row&)
What do you think?
Someone with experience using the library and a better understanding than myself should comment. But I noticed in the postgres-asio example you declare auto stmt = conn.prepare_statement("UPDATE mytable SET f1 = $1 WHERE f2 = $2"); In the mysql exaples you did not use auto, I presume this style is possible also in mysql, then maybe not worth changing signatures as it is not such a big deal. Cheers, Kostas
participants (2)
-
Kostas Savvidis
-
Ruben Perez