Changes in MySQL Connector/J 8.0.32 (2023-01-17, General Availability)

Version 8.0.32 is the latest General Availability release of the 8.0 series of MySQL Connector/J. It is suitable for use with MySQL Server versions 8.0 and 5.7. It supports the Java Database Connectivity (JDBC) 4.2 API, and implements the X DevAPI.

• Installation and Compilation Notes

• Functionality Added or Changed

• Bugs Fixed

Installation and Compilation Notes

• The version requirements for the third-party libraries and tools needed for running and building Connector/J 8.0.32 have been updated. See Connector/J Installation and Installing from Source for details. (WL #15468, WL #15411)

Functionality Added or Changed

• The databaseName in MysqlDataSource is now URL encoded in the JDBC URL that is being constructed using it. Thanks to Jared Lundell for his contributions to the patch. (Bug #33361205)

• The Ant build script for Connector/J has been updated to produce artifacts compliant with Maven central repository's publishing requirements. (WL #15437)

Bugs Fixed

• The Maven relocation POM that was supposed to redirect users of the old Connector/J Maven coordinates to the new ones had a wrong file name, which has now been corrected. Thanks to Henning Pöttker for contributing to the fix. (Bug #108814, Bug #34717205)

• When Connector/J looked for the presence of the ON DUPLICATE KEY UPDATE clause in prepared statements, it neglected the cases where the VALUES function was used without the VALUE(S) clause in INSERT statements. As a result, some statements that actually had the ON DUPLICATE KEY UPDATE clause were not caught, resulting in incorrect information for generated keys. Thanks to Yamasaki Tadashi for contributing to the fix. (Bug #108419, Bug #34578010)

• When using server-side prepared statements, the BIT data type was not properly handled by NativeQueryBindValue.getFieldType() and, as a result, BIT values were being mapped to FIELD_TYPE_VAR_STRING and causing malformed packets. This patch fixes this by mapping BIT values to FIELD_TYPE_TINY, so that the values will be handled correctly when the prepared statement is executed on the server. Thanks to Seongman Yang for contributing to the patch. (Bug #108414, Bug #34578541)

• Before executing a query with Statement.executeQuery(query), Connector/J checks if the query is going to produce results and rejects it if it cannot. The check wrongly rejected queries that had a WITH clause using a common table expression and a UNION operator, and had the first SELECT statement put between parentheses. (Bug #108195, Bug #34512212)

• Calls of the valueOf() method of the native types' wrapper classes have been replaced by the corresponding parse[Type]() methods in order to avoid unnecessary boxing. Thanks to Andrey Turbanov for contributing to the patch. (Bug #106981, Bug #34059340)

• When working with MySQL Server 5.7.5 or earlier, if server-side prepared statements were used, Connector/J sometimes hung after the prepare phase for a statement. It was caused by Connector/J mistaking a metadata packet as an EOF packet and discarding it by mistake. With this fix, the mistake is avoided by improving the procedure for handling EOF packets. Thanks to Zhe Huang for contributing to the fix. (Bug #106252, Bug #33968169)

• Prepared statements that contained EXPLAIN queries and used a cursor could not return any results. (Bug #102678, Bug #32536384)

• With the prepared statement cache enabled, a server-side prepared statement obtained from the cache always maintained its old result set type even after that had been changed in a new Connection.prepareStatement() call. This patch fixes that behavior by resetting properly the result set type value of the cached statement for each new query. (Bug #102520, Bug #32476663)

• Insert statements with ON DUPLICATE KEY UPDATE that used value aliases caused a syntax error when the batched statements were being rewritten. It was because the value alias were being added repeatedly after each value group while only one alias was expected. This fix eliminates the undue repetitions. (Bug #99604, Bug #31612628)

• Because the value of a MySQL unsigned INTEGER can be larger than what a Java int can hold, a MySQL unsigned INTEGER must be handled as a Java long. However, the rule was not followed by UpdatableResultSet and a couple of ValueEncoders in Connector/J , causing invalid numeric conversions when the unsigned integers were very large. (Bug #68608, Bug #16690898)