The following features are new, compared to the 5.0 series of Connector/J
JDBC-4.0 support for setting per-connection client information (which can be viewed in the comments section of a query using
SHOW PROCESSLISTon a MySQL server, or can be extended to support custom persistence of the information using a public interface).Support for JDBC-4.0 XML processing using JAXP interfaces to DOM, SAX and StAX.
JDBC-4.0 standardized unwrapping to interfaces that include vendor extensions.
Functionality added or changed:
Connector/J now connects using an initial character set of
utf-8solely for the purpose of authentication to permit user names or database names in any character set to be used in the JDBC connection URL. (Bug#29853)Added two configuration parameters:
blobsAreStrings: Should the driver always treat BLOBs as Strings. Added specifically to work around dubious metadata returned by the server forGROUP BYclauses. Defaults to false.functionsNeverReturnBlobs: Should the driver always treat data from functions returningBLOBsas Strings. Added specifically to work around dubious metadata returned by the server forGROUP BYclauses. Defaults to false.
Setting
rewriteBatchedStatementstotruenow 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.The driver now picks appropriate internal row representation (whole row in one buffer, or individual byte[]s for each column value) depending on heuristics, including whether or not the row has
BLOBorTEXTtypes and the overall row-size. The threshold for row size that will cause the driver to use a buffer rather than individual byte[]s is configured by the configuration propertylargeRowSizeThreshold, which has a default value of 2KB.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.Added experimental support for statement "interceptors" through the
com.mysql.jdbc.StatementInterceptorinterface, examples are incom/mysql/jdbc/interceptors. Implement this interface to be placed "in between" query execution, so that it can be influenced (currently experimental).The driver will automatically adjust the server session variable
net_write_timeoutwhen it determines its been asked for a "streaming" result, and resets it to the previous value when the result set has been consumed. (The configuration property is namednetTimeoutForStreamingResults, with a unit of seconds, the value '0' means the driver will not try and adjust this value).JDBC-4.0 ease-of-development features including auto-registration with the
DriverManagerthrough the service provider mechanism, standardized Connection validity checks and categorizedSQLExceptionsbased on recoverability/retry-ability and class of the underlying error.Statement.setQueryTimeout()s now affect the entire batch for batched statements, rather than the individual statements that make up the batch.Errors encountered during
Statement/PreparedStatement/CallableStatement.executeBatch()whenrewriteBatchStatementshas been set totruenow returnBatchUpdateExceptionsaccording to the setting ofcontinueBatchOnError.If
continueBatchOnErroris set totrue, the update counts for the "chunk" that were sent as one unit will all be set toEXECUTE_FAILED, but the driver will attempt to process the remainder of the batch. You can determine which "chunk" failed by looking at the update counts returned in theBatchUpdateException.If
continueBatchOnErroris set to "false", the update counts returned will contain all updates up-to and including the failed "chunk", with all counts for the failed "chunk" set toEXECUTE_FAILED.Since MySQL doesn't return multiple error codes for multiple-statements, or for multi-value
INSERT/REPLACE, it is the application's responsibility to handle determining which item(s) in the "chunk" actually failed.New methods on com.mysql.jdbc.Statement:
setLocalInfileInputStream()andgetLocalInfileInputStream():setLocalInfileInputStream()sets anInputStreaminstance that will be used to send data to the MySQL server for aLOAD DATA LOCAL INFILEstatement rather than aFileInputStreamorURLInputStreamthat represents the path given as an argument to the statement.This stream will be read to completion upon execution of a
LOAD DATA LOCAL INFILEstatement, and will automatically be closed by the driver, so it needs to be reset before each call toexecute*()that would cause the MySQL server to request data to fulfill the request forLOAD DATA LOCAL INFILE.If this value is set to
NULL, the driver will revert to using aFileInputStreamorURLInputStreamas required.getLocalInfileInputStream()returns theInputStreaminstance that will be used to send data in response to aLOAD DATA LOCAL INFILEstatement.This method returns
NULLif no such stream has been set usingsetLocalInfileInputStream().
Setting
useBlobToStoreUTF8OutsideBMPtotruetells the driver to treat[MEDIUM/LONG]BLOBcolumns as[LONG]VARCHARcolumns holding text encoded in UTF-8 that has characters outside the BMP (4-byte encodings), which MySQL server can't handle natively.Set
utf8OutsideBmpExcludedColumnNamePatternto a regex so that column names matching the given regex will still be treated asBLOBsThe regex must follow the patterns used for thejava.util.regexpackage. The default is to exclude no columns, and include all columns.Set
utf8OutsideBmpIncludedColumnNamePatternto specify exclusion rules to utf8OutsideBmpExcludedColumnNamePattern". The regex must follow the patterns used for thejava.util.regexpackage.
Bugs fixed:
setObject(int, Object, int, int)delegate in PreparedStatmentWrapper delegates to wrong method. (Bug#30892)NPE with null column values when
padCharsWithSpaceis set to true. (Bug#30851)Collation on
VARBINARYcolumn types would be misidentified. A fix has been added, but this fix only works for MySQL server versions 5.0.25 and newer, since earlier versions didn't consistently return correct metadata for functions, and thus results from subqueries and functions were indistinguishable from each other, leading to type-related bugs. (Bug#30664)An
ArithmeticExceptionorNullPointerExceptionwould be raised when the batch had zero members andrewriteBatchedStatements=truewhenaddBatch()was never called, orexecuteBatch()was called immediately afterclearBatch(). (Bug#30550)Closing a load-balanced connection would cause a
ClassCastException. (Bug#29852)Connection checker for JBoss didn't use same method parameters using reflection, causing connections to always seem "bad". (Bug#29106)
DatabaseMetaData.getTypeInfo()for the typesDECIMALandNUMERICwill return a precision of 254 for server versions older than 5.0.3, 64 for versions 5.0.3 to 5.0.5 and 65 for versions newer than 5.0.5. (Bug#28972)CallableStatement.executeBatch()doesn't work when connection propertynoAccessToProcedureBodieshas been set totrue.The fix involves changing the behavior of
noAccessToProcedureBodies,in that the driver will now report all paramters asINparamters but permit callers to call registerOutParameter() on them without throwing an exception. (Bug#28689)DatabaseMetaData.getColumns()doesn't containSCOPE_*orIS_AUTOINCREMENTcolumns. (Bug#27915)Schema objects with identifiers other than the connection character aren't retrieved correctly in
ResultSetMetadata. (Bug#27867)Connection.getServerCharacterEncoding()doesn't work for servers with version >= 4.1. (Bug#27182)The automated SVN revisions in
DBMD.getDriverVersion(). The SVN revision of the directory is now inserted into the version information during the build. (Bug#21116)Specifying a "validation query" in your connection pool that starts with "/* ping */" _exactly_ will cause the driver to instead send a ping to the server and return a fake result set (much lighter weight), and when using a ReplicationConnection or a LoadBalancedConnection, will send the ping across all active connections.