This is a new Alpha development release, adding new features and fixing recently discovered bugs.
Incompatible Change: Pulled vendor-extension methods of
Connectionimplementation out into an interface to support
ConnectionPoolDataSource. The vendor extensions are javadoc'd in the
For those looking further into the driver implementation, it is not an API that is used for pluggability of implementations inside our driver (which is why there are still references to
ConnectionImplthroughout the code).
We've also added server and client
prepareStatement()methods that cover all of the variants in the JDBC API.
Connection.serverPrepare(String)has been re-named to
Connection.serverPrepareStatement()for consistency with
See the sources (fully javadoc'd) for
com.mysql.jdbc.StatementInterceptorfor more details until we iron out the API and get it documented in the manual.
Externalized the descriptions of connection properties.
CallableStatementswith batched arguments to be re-written in the form
CALL (...); CALL (...); ...to send the batch in as few client/server round trips as possible.
Added experimental support for statement "interceptors" through the
com.mysql.jdbc.StatementInterceptorinterface, examples are in
Implement this interface to be placed "in between" query execution, so that you can influence it. (currently experimental).
StatementInterceptorsare "chainable" when configured by the user, the results returned by the "current" interceptor will be passed on to the next on in the chain, from left-to-right order, as specified by the user in the JDBC configuration property
Made it possible to retrieve prepared statement parameter bindings (to be used in
Connection, we pulled out vendor extensions to
Statementinto an interface named
com.mysql.Statement, and moved the
com.mysql.StatementImpl. The two methods (javadoc'd in
enableStreamingResults(), which already existed, and
disableStreamingResults()which sets the statement instance back to the fetch size and result set type it had before
The data (and how it is stored) for
ResultSetrows are now behind an interface which enables us (in some cases) to allocate less memory per row, in that for "streaming" result sets, we re-use the packet used to read rows, since only one row at a time is ever active.
Row navigation now causes any streams/readers open on the result set to be closed, as in some cases we're reading directly from a shared network packet and it will be overwritten by the "next" row.
Driver now picks appropriate internal row representation (whole row in one buffer, or individual bytes for each column value) depending on heuristics, including whether or not the row has
TEXTtypes and the overall row-size. The threshold for row size that will cause the driver to use a buffer rather than individual bytes is configured by the configuration property
largeRowSizeThreshold, which has a default value of 2KB.