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
forUPDATE
andDELETE
. Extended slow query warning with query execution plan forINSERT
,REPLACE
,UPDATE
, andDELETE
.
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
, orlocatorFetchBufferSize
, 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 toXAException.XAER_DUPID
. (Bug #16979862, Bug #69506)The
SYSTEM TABLE
type was handled inconsistently in different methods:DatabaseMetaData.getTableTypes()
did not return system tables, andDatabaseMetaData.getTables()
did not return all system tables. With this fix, the table typesSYSTEM TABLE
andSYSTEM VIEW
are returned bygetTableTypes()
, andgetTables()
now returns tables from the internal schemasmysql
andperformance_schema
as instances ofSYSTEM TABLE
and tables frominformation_schema
as instances ofSYSTEM 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
anduseAffectedRows=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 anON 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 methodResultSet.getMetaData().getColumnClassName()
still returned the Java type of aYEAR
column asjava.sql.Date
although internally it was being treated asjava.sql.Short
. This fix corrects the metadata for aYEAR
column under this situation, so that the correct Java type ofjava.sql.Short
is returned. Please note that the methodResultSet.getMetaData().getColumnType()
, however, returnsjava.sql.Types.DATE
irrespective of theyearIsDateType
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)