MySQL Connector/J 5.1 Release Notes
Version 5.1.27 is a maintenance release of the MySQL Connector/J production 5.1 branch. It is suitable for use with many MySQL Server versions, including 4.1, 5.0, 5.1, 5.4, 5.5 and 5.6.
Added support for multi-master replication topographies, which
can now be specified using the following host definition syntax:
address=(host=hostname)(port=3306)(type=[master|slave])
.
Added the flag
CLIENT_PLUGIN_AUTH_LENENC_CLIENT_DATA
and
support for authentication data up to a length of
264-1 bytes.
Added support for EXPLAIN
for
UPDATE
and DELETE
.
Extended slow query warning with query execution plan for
INSERT
, REPLACE
,
UPDATE
, and DELETE
.
When attempting to connect to a server using long, multibyte user name and database name, an Array Index Out Of Bounds Exception was thrown. This fix prevents the problem by increasing the space reserved for those strings. (Bug #17251955)
When setting a connection property with a value for
blobSendChuckSize
,
largeRowSizeThreshold
, or
locatorFetchBufferSize
, the suffix
“G” was not recognized and caused an error to be
thrown. With this fix, Connector/J now supports using
“G” or “GB” for gigabyte for the
purpose, as well as “KB” for kilobyte and
“MB” for megabyte.
(Bug #17015673, Bug #69452)
When there was an attempt to create a second branch with a
duplicate ID on the same MySQL server instance, the
XAException.errorCode
returned by Connector/J
was not equal to XAException.XAER_DUPID
.
(Bug #16979862, Bug #69506)
The SYSTEM TABLE
type was handled
inconsistently in different methods:
DatabaseMetaData.getTableTypes()
did not
return system tables, and
DatabaseMetaData.getTables()
did not return
all system tables. With this fix, the table types
SYSTEM TABLE
and SYSTEM
VIEW
are returned by
getTableTypes()
, and
getTables()
now returns tables from the
internal schemas mysql
and
performance_schema
as instances of
SYSTEM TABLE
and tables from
information_schema
as instances of
SYSTEM VIEW
.
(Bug #16879239, Bug #69290)
JDBC authentication failed when there was a null byte in the
scramble, because
com.mysql.jdbc.MysqlIO.doHandshake
only read
up to the first null byte when reading in the first eight bytes
of the scramble.
(Bug #16723048, Bug #62469)
When rewriteBatchedStatements=true
and
useAffectedRows=true
were set,
executeBatch()
did not return the number of
affected rows as expected, but always returned a
“1,” even if no rows were affected (for example,
when an ON DUPLICATE KEY UPDATE
clause was
applicable but the data needed no changes). The “1”
was actually a hardwired value, a workaround for a known issue
on the server side, which does not return the number of affected
rows in such cases. This fix makes Connector/J just return the
value given by the server anyway, which means the returned
number of affected rows is reliable now if Connector/J returns a
“0” [no rows affected]; nonzero values returned
should not be trusted, though.
(Bug #16442951, Bug #68562)
In a replication-aware deployment, when the master was not
reachable, new connections could not be made, or the replication
driver just hung. As part of the new multiple-master support
feature, users can now set the property
allowMasterDownConnections=true
to allow
connections to be established even when no master hosts are
available.
(Bug #11757979, Bug #50105, Bug #16443992, Bug #63354)
Calling ResultSet.absolute(0) caused Connector/J to throw an error. This fix makes ResultSet.absolute(0) behave like ResultSet.beforeFirst(), as required by the JDBC specifications. (Bug #11749136, Bug #38252)
After setting the connection property
yearIsDateType=false
, the method
ResultSet.getMetaData().getColumnClassName()
still returned the Java type of a YEAR
column
as java.sql.Date
although internally it was
being treated as java.sql.Short
. This fix
corrects the metadata for a YEAR
column under
this situation, so that the correct Java type of
java.sql.Short
is returned. Please note that
the method
ResultSet.getMetaData().getColumnType()
,
however, returns java.sql.Types.DATE
irrespective of the yearIsDateType
setting.
(Bug #11748097, Bug #35115)
The string returned by
DatabaseMetaData.getDriverVersion()
contains
the unexpanded expression “${svn.Revision}” or
“${bzr.revision-id}” instead of the actual revision
number of Connector/J.
(Bug #50538, Bug #11758345)