Hi Ruben, Ruben Perez wrote:
This library is supposed to be a protocol driver library, so it provides primitives close to the MySQL protocol.
It's frustrating to see this now, after writing my review. I thought I was reviewing a library that, quoting your docs, made "ease of use" its first design goal and aimed to "hide the MySQL protocol complexities". Make up your mind, are you trying to hide the protocol or provide something close to it? And in a later message: Ruben Perez wrote:
When sending two queries [...] You could also initiate the next query without completely reading all the packets sent by the server. [...] This is possible at the protocol level. [...] This [...] is *currently not possible* with the current [library] interface.
Contrast that with what your docs say: Warning Because of how the MySQL protocol works, once you obtain a resultset, you must read it entirely (i.e. until it's complete) before engaging in any subsequent operation that implies communication with the server (e.g. issuing another query, preparing a statement, closing a statement...). Failing to do so results in undefined behavior. You are explicitly blaming the protocol for this restriction in that quote. It seems that that is not true, and that it is a limitation of the library. If I were writing my review again on the basis of this being a low-level protocol library - which I'm not going to do, I don't have time - I would probably say that support for this sort of pipelining is essential. I would perhaps hope to see "low-level" functions that encode and decode the protocol packets, which the user could even use with their own networking layer, if they wanted to.
Pipeline modes usually specify an option on what to do when a query in the pipeline fails. Here, you don't have that - subsequent queries will be executed regardless of the result of previous ones.
Transactions help here though. For example: Transaction t(conn); for (auto&& a: lots_of_things) { execute_insert_stmt(a); } t.commit(); I would expect pipelining to significantly improve the performance of that, especially if there were significant network latency. Regards, Phil.