MeanSquaredError

@rbock IMHO the amount of work is not that much of a problem. I am more worried about possible name clashes. If removing the _t suffixes is OK for you,...

Being able to unsubscribe without actually closing the connection is a rather useful feature. Are there any plans to merge that into the master branch?

@damian-tomczak It seems that there is an unwanted `#endif` around line 91 ``` #if MYSQL_VERSION_ID < 80034 if (config->auto_reconnect) { my_bool my_true{true}; @@ -87,6 +88,10 @@ namespace sqlpp throw sqlpp::exception{"MySQL:...

@damian-tomczak If I understand correctly, they are deprecating not just the reconnect option, but the reconnect functionality as a whole. Here https://dev.mysql.com/doc/c-api/8.0/en/c-api-auto-reconnect.html they say the following > Beginning with MySQL...

On a side note, I always considered MYSQL's reconnect a useless and even harmful feature because it does not preserve transactions. Any serious application uses transactions and thus cannot use...

@damian-tomczak The question is what is the purpose of the PR? Is it to silence the warnings or something else? It seems that the purpose of the patch is to...

Currently I see several possible approaches: 1. Don't apply this PR, leave everything as it is now. Once the MySQL client library stops supporting reconnects, use ifdefs to disable reconnects...

@rbock I think it is a good approach. It is probably also worth mentioning in the documentation that if the old behavior is really needed and the user doesn't want...

Actually the same pattern (atomic_block_of_work) is useful for handling all kinds of transaction failures, not just network errors. For example using pessimistic locking (`LOCK tablename, ...`) gets really complicated when...

@rbock > I am thinking of backporting minimal versions of `optional`, `string_view`, and `span` into the library for versions the don't support them (type aliased if supported). +1 to that....