This is a new Alpha development release, adding new features and fixing recently discovered bugs.
Functionality Added or Changed
Pulled vendor-extension methods of
implementation out into an interface to support
java.sql.Wrapper functionality from
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
ConnectionImpl throughout 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
true now causes
CallableStatements with batched arguments to
be re-written in the form
CALL (...); CALL (...);
... to send the batch in as few client/server round
trips as possible.
See the sources (fully javadoc'd) for
com.mysql.jdbc.StatementInterceptor for more
details until we iron out the API and get it documented in the
Added experimental support for statement "interceptors" through
interface, examples are in
Implement this interface to be placed "in between" query execution, so that you can influence it. (currently experimental).
StatementInterceptors are "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
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
TEXT types 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.
Connection, we pulled out vendor
Statement into an interface
com.mysql.Statement, and moved the
Statement class into
com.mysql.StatementImpl. The two methods
enableStreamingResults(), which already
sets the statement instance back to the fetch size and result
set type it had before
enableStreamingResults() was called.
The data (and how it is stored) for
rows 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.
Externalized the descriptions of connection properties.
Made it possible to retrieve prepared statement parameter
bindings (to be used in
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.