MySQL Connector/J 8.0.25 has been released

Dear MySQL users,

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

This release includes the following new features and changes, also described in
more detail on

https://dev.mysql.com/doc/relnotes/connector-j/8.0/en/news-8-0-25.html

As always, we recommend that you check the “CHANGES” file in the download
archive to be aware of changes in behavior that might affect your application.

To download MySQL Connector/J 8.0.25 GA, see the “General Availability (GA)
Releases” tab at http://dev.mysql.com/downloads/connector/j/

Enjoy!

Changes in MySQL Connector/J 8.0.25 (2021-05-11, General Availability)

This release contains no functional changes and is published
  to align the version number with the MySQL Server 8.0.25
  release.

On Behalf of the MySQL Engineering Team,
Surabhi Bhat

Support EOL for MySQL Connector/J 5.1

Per Oracle’s Lifetime Support policy, as of Feb 9th, 2021, MySQL Connector/J 5.1 series is covered under Oracle Sustaining Support. Downloadable binaries can be found in the MySQL Products Archives and in the Maven Central Repository.

MySQL Connector/J 5.1.49 has been the last release of Connector/J 5.1 series.

It is time to move on. Users are encouraged to upgrade to MySQL Connector/J 8.0 series which provides the same features as Connector/J 5.1 and a lot more, including a brand new date/time handling support, introduced in version 8.0.23, and the X DevAPI that empowers the MySQL Document Store.

We like to hear from you. Please join us in the MySQL Forums or in #connectors channel in:

Support for Date-Time Types in Connector/J 8.0

Connector/J version 8.0.23 came out with several bug fixes related to date-time types support. They provide more flexibility for configuring time zone handling and allow migration from Connector/J 5.1 with much less effort.

Problems with migration from Connector/J 5.1 to Connector/J 8.0 were caused by the early decision that Connector/J 8.0 should always try to preserve an instant point on the time-line while Connector/J 5.1 does it optionally and, by default, preserves the original visual representation.

For example, the following code will store different results with Connector/J 5.1 and Connector/J 8.0 in case the client and server time zones are different:

Statement st = conn.createStatement();
st.executeUpdate("CREATE TABLE t1 (ts TIMESTAMP)");

PreparedStatement ps = conn.prepareStatement("INSERT INTO t1 VALUES (?)");
ps.setTimestamp(1, Timestamp.valueOf("2020-01-01 12:00:00"));
ps.executeUpdate();

If the client is running in the UTC+2 time zone and server is running in UTC+1 the internal value of the TIMESTAMP field will be “2020-01-01 11:00:00Z” with Connector/J 5.1 but “2020-01-01 10:00:00Z” with Connector/J 8.0.

Another client in the UTC+3 time zone is reading this value:

ResultSet rs = st.executeQuery("SELECT * FROM t1");
Timestamp ts = rs.getTimestamp(1);

The result will be “2020-01-01 12:00:00” with Connector/J 5.1 but “2020-01-01 13:00:00” with Connector/J 8.0.

By default, Connector/J 5.1 sends values as they are rendered locally and, on retrieval, constructs values using the client’s local time zone. Thus, the visual representation remains the same in any client time zone and on the server. But the internal UTC value of a TIMESTAMP could be different from an expected instant value.

Connector/J 8.0.22 and before converts the original value to the session time zone before sending, thus the internal UTC value of a TIMESTAMP matches the expected instant value. When retrieved, a value is constructed after converting the on-wire value from session time zone to the local one, so it still represents the same instant, but the visual representation is different in different client time zones.

Actually both approaches are valid use cases. You probably don’t care about the real internal TIMESTAMP value if you don’t do any server-side calculations with it. But you might want to store the instant point on the time-line, like for a Zoom meeting start time, in other cases. Both ways are now possible with Connector/J 8.0.23. The following connection properties define the time zone handling:

  • connectionTimeZone=LOCAL|SERVER|user-defined time zone (previously known as ‘serverTimezone’, now with additional fixed values) defines how the server’s session time zone is to be determined by Connector/J.
  • forceConnectionTimeZoneToSession=true|false controls whether the session time_zone variable is to be set to the value specified in ‘connectionTimeZone’.
  • preserveInstants=true|false turns on|off the conversion of instant values between JVM and ‘connectionTimeZone’.

The most useful configurations are:

  • connectionTimeZone=LOCAL & forceConnectionTimeZoneToSession=false – corresponds with the Connector/J 5.1 behavior with useLegacyDatetimeCode=true.
  • connectionTimeZone=LOCAL & forceConnectionTimeZoneToSession=true – the new mode which provides the most natural way for handling date-time values.
  • connectionTimeZone=SERVER & preserveInstants=true – corresponds to the previous Connector/J 8.0 behavior and Connector/J 5.1 behavior with useLegacyDatetimeCode=false.
  • connectionTimeZone=user_defined & preserveInstants=true – helps to overcome the situation when the server time zone cannot be recognized by the connector because it is set as a generic abbreviation like CET/CEST.

More details are given below, but first let’s define what exactly we mean when talking about “instant date-time classes” and “instant MySQL types”.

Supported MySQL date-time data types

The MySQL TIMESTAMP is the only data type designed to store instant points on the time-line using the implied time zone conversion. Incoming values are converted by server from the session time zone to UTC for storage, and outgoing values are converted from UTC to the session time zone. There is no way to preserve the original time zone but even if the session time zone was altered, the retrieved value still represents the same instant point on the time-line. Starting from MySQL 8.0.19, you can also specify a time zone offset when storing TIMESTAMP values (see “The DATE, DATETIME, and TIMESTAMP Types”). In such case the incoming values are converted to UTC from the specified offset instead of the session time zone. But, finally, the original offset is also lost.

The MySQL YEAR represents only the year number, DATE is missing a time part, TIME is missing the date part. So, they are definitely not instant types.

The situation with MySQL DATETIME data type is less straightforward. There is no implied time zone conversion for this type; values are stored and retrieved as they are, so this type could be taken as an analog of Java LocalDateTime. However, with the new syntax available since MySQL 8.0.19, when a value with offset is stored to a DATETIME column, it is converted to the session time zone!

New-style DATETIME values are consistent with old-style ones and the retrieved results are consistent only when client’s and session time zones are the same.

Therefore, it is more correct to say that server assumes that local date-time values coming to DATETIME always belong to the session time zone. In any case, DATETIME is not an instant type: there is no time zone information associated with a stored DATETIME value.

Users sometimes store Timestamps to DATETIME instead of TIMESTAMP because of wider ranges of represented values (‘1000-01-01 00:00:00.000000’ to ‘9999-12-31 23:59:59.999999’ against ‘1970-01-01 00:00:01.000000Z’ to ‘2038-01-19 03:14:07.999999Z’ respectively). It is possible to use DATETIME and still leverage the capability of preserving instants but with some limitations. See details in preserveInstants property description below.

Supported Java date-time classes

Connector/J 8.0.23 considers following date-time classes as “non-instant” ones even when some of them are extending the java.util.Date:

  • java.sql.Date – The time components are set to zeros.
  • java.sql.Time – The date components are set to the “zero epoch” value.
  • java.time.LocalDate – The time components and time zone are not defined.
  • java.time.LocalTime – The date components and time zone are not defined.
  • java.time.LocalDateTime – The time zone is not defined.
  • java.time.OffsetTime – The date components are not defined.

Supported “instant” date-time classes are:

  • java.util.Calendar
  • java.util.Date
  • java.sql.Timestamp
  • java.time.OffsetDateTime
  • java.time.ZonedDateTime

Preserving instants

First, let’s enumerate the time zones we are dealing with:

  • MySQL TIMESTAMP internal time zone– it’s always UTC.
  • MySQL session time zone – the per-client “on-wire” time zone, specified in the time_zone system variable. By default, the initial value of this is ‘SYSTEM’, which means, “use the value of system_time_zone”, but it may be redefined at server startup with the –default-time-zone option.
  • Client local time zone – the JVM default time zone. By default, it is equal to the client system time zone but can be changed by an application.
  • Original time zone – Objects based on java.util.Date are associated with the JVM time zone by default, but java.util.Calendar, java.time.OffsetDateTime and java.time.ZonedDateTime have an explicit time zone.

So, MySQL never stores a date-time value with its original time zone but it always assumes that this value is correctly represented in the session time zone. It means that in order to preserve the instant value, Connector/J should adjust it to the session time zone before sending to server. It can be done in different ways. Either Connector/J converts the value from the original time zone to the session time zone and then sends it, or Connector/J could set the session time zone equal to the local one so that no conversion is needed then except for java.util.Calendar, java.time.OffsetDateTime, and java.time.ZonedDateTime values, which should be converted to the local time zone.

Connector/J will never try to preserve the instant value if either the source class or the target type are not of the instant-based ones, even if Connector/J is configured to preserve instant. For example, if java.sql.Date is sent as SQL TIMESTAMP, it is rendered in the local time zone, if java.sql.Timestamp is sent as SQL DATE it is also rendered in the local time zone. But when java.sql.Timestamp is sent as SQL TIMESTAMP the value will be adjusted to the session time zone.

For example, with client time zone UTC+2, session time zone UTC+1 and connection is created with connectionTimeZone=SERVER&preserveInstants=true:

import com.mysql.cj.MysqlType;
...
ps = conn.prepareStatement("INSERT INTO t1 VALUES (?)");

ps.setObject(Date.valueOf("2020-01-01"), MysqlType.DATE);
ps.executeUpdate(); // sends "INSERT INTO t1 VALUES ('2020-01-01')"

ps.setObject(Date.valueOf("2020-01-01"), MysqlType.TIMESTAMP);
ps.executeUpdate(); // sends "INSERT INTO t1 VALUES ('2020-01-01 00:00:00')"

ps.setObject(Timestamp.valueOf("2020-01-01 00:00:00"), MysqlType.TIMESTAMP);
ps.executeUpdate(); // sends "INSERT INTO t1 VALUES ('2019-12-31 23:00:00')"

Please note, that the target type is not necessarily the real target column type. Connector/J has two implementations of PreparedStatement. ServerPreparedStatement is really prepared on the server side and returns the parameters’ metadata on prepare. But the ClientPreparedStatement is prepared on the client side and sent as a plain query on execute, thus no parameters metadata is available there. Since Connector/J could switch between these implementations internally on some conditions, they should perform identically. Thus, for the sake of consistency, the parameters metadata is not used, the decision about sent value is always based only on the default JDBC Type for the used Java class, as defined in TABLE B-4 of the JDBC specification, or on the explicitly defined target JDBC Type in a setObject() call.

MySQL DATETIME is a non-standard type but it matches perfectly with the LocalDateTime class by nature, thus the default target type for LocalDateTime is MysqlType.DATETIME instead of TIMESTAMP, as per the JDBC specification.

Time zone configuration properties

  • connectionTimeZone=LOCAL|SERVER|user-defined time zone. The ‘serverTimezone’ property was renamed to ‘connectionTimeZone’ in order to highlight that it does not necessary match the real server or session time zone. It just informs the connector which time zone should be used in cases where the instant value must be converted between the JVM and the on-wire time zones. If it is set to “LOCAL” (which is the default value, if the property is not specified) the driver assumes that the connection time zone is the same as the JVM default time zone. If set to “SERVER” then the driver attempts to detect the session time zone from the values configured on the MySQL server session variables “time_zone” or “system_time_zone”. An explicit value must be a geographic time zone name or a time zone offset from Greenwich/UTC, using a syntax java.time.ZoneId is able to parse.

This option itself does not set MySQL server session variable ‘time_zone’ to the given value. To do that the ‘forceConnectionTimeZoneToSession’ connection option must be set to “true”.

Please note that setting a value to ‘connectionTimeZone’ in conjunction with ‘forceConnectionTimeZoneToSession=false’ and ‘preserveInstants=false’ has no effects since, in that case, connectionTimeZone is used neither to change the session time zone nor to convert the time zone.

  • forceConnectionTimeZoneToSession=true|false. If it is set to “false” (which is the default value) the session time zone is left unchanged on the server. When this property is set to “true”, the driver sets the time zone value determined by ‘connectionTimeZone’ connection property to the current server session ‘time_zone’ variable.

Please be aware that altering the session time zone also affects the result of MySQL functions such as ‘NOW()’, ‘CURTIME()’ or ‘CURDATE()’.

This option has no effect if used in conjunction with ‘connectionTimeZone=SERVER’ since, in this case, you are requesting the session time zone to be set to the value it already has.

  • preserveInstants=true|false. With ‘preserveInstants=false’ Connector/J 8.0.23 always uses the JVM default time zone for rendering the values it sends to the server and for constructing the Java objects from the fetched data. It matches the default Connector/J 5.1 behavior. If ‘preserveInstants=true’ (which is the default value), Connector/J does its best to preserve the instant point on the time-line for Java instant-based objects such as java.sql.Timestamp or java.time.OffsetDateTime, instead of preserving the time’s original visual form. When storing, the conversion is performed only if the target SQLType, either the explicit one or the default one, is TIMESTAMP. When retrieving, the conversion is performed only if the source column has the TIMESTAMP, DATETIME or character type and the target class is an instant-based one, like java.sql.Timestamp or java.time.OffsetDateTime.

This option has no effect if used in conjunction with ‘connectionTimeZone=LOCAL’ since, in this case, the source and target time zones are the same.

Conversion between original time zone and session time zone has a risk of altering the value in case they have incompatible DST rules.

Time zone configurations

  • connectionTimeZone=LOCAL & forceConnectionTimeZoneToSession=false. No time zone conversion is done by the driver because it assumes that the session time zone equals to the local one. The actual session time zone is left untouched and it is the same for all clients. That’s the way for keeping the same visual date-time value representation. Instants may be kept correctly only when all clients and the server are actually residing in the same time zone.

This configuration corresponds to the default Connector/J 5.1 behavior (with useLegacyDatetimeCode=true).

  • connectionTimeZone=LOCAL & forceConnectionTimeZoneToSession=true. This new mode provides the most natural way for handling date-time values. Connector/J sets the session time zone equal to the local one and always uses the local time zone internally. Server converts a TIMESTAMP to its internal UTC value directly from the client time zone eliminating possible problems with DST. It’s also safe to use both the old syntax and the extended syntax with zone offset for setting DATETIMEs–they are finally adjusted to the same session time zone.

Since different clients in this mode might change their individual session into different time zones, this mode does not allow the same visual date-time value representation to be kept in a TIMESTAMP column; store the value to a DATETIME column instead.

And, again, altering the session time zone also affects the result of MySQL functions such as ‘NOW()’, ‘CURTIME()’ or ‘CURDATE()’.

  • connectionTimeZone=SERVER & preserveInstants=true. The session time zone is left untouched and it is the same for all clients. The driver converts instant values to the session time zone when they are sent as a TIMESTAMP. When retrieving, the driver converts values from the session time zone to the local one if the source column is in the TIMESTAMP, DATETIME or character type and the target class is an instant-based one.

This configuration corresponds to the previous Connector/J 8.0 behavior and Connector/J 5.1 behavior with useLegacyDatetimeCode=false.

  • connectionTimeZone=user_defined & preserveInstants=true. Without changing the session time zone on the server, this setup helps to overcome the situation in which the server time zone cannot be recognized by the connector because it is set with an unrecognizable, generic abbreviation like CET or CEST. This configuration gives Connector/J the proper time zone identification for the session, to which the timestamps should be converted.

OffsetDateTime and ZonedDateTime support

The original time zone of java.time.OffsetDateTime and java.time.ZonedDateTime is never preserved when they are stored to the date-time column. The driver first converts the date-time values into the local time zone and then, if it is preserving instants, it converts them to the session time zone.

When the driver reads instants from the server into these objects and it is configured to preserve instants, the result will be constructed with the session time zone. Otherwise, result will be constructed with the local time zone.

For example, with client time zone UTC+2, session time zone UTC+1 and the connection created with connectionTimeZone=SERVER&preserveInstants=true:

import com.mysql.cj.MysqlType;
...
ps = conn.prepareStatement("INSERT INTO t1 VALUES (?)");

ps.setObject(OffsetDateTime.parse("2020-01-01T13:00:00+03:00"));
ps.executeUpdate();
// sends "INSERT INTO t1 VALUES ('2020-01-01 11:00:00')"

ResultSet rs = st.executeQuery("SELECT * FROM t1");
String odt = rs.getObject(1, OffsetDateTime.class).toString();
// returns "2020-01-01T11:00:00+01:00"

Fractional seconds support

New connection property sendFractionalSecondsForTime=true|false tells the driver to send or ignore the fractional seconds contained in java.sql.Time.

This option overrides the inconsistency between MySQL TIME and JDBC java.sql.Time. While MySQL TIME may store fractional seconds the java.sql.Time is defined as a time value without a fractional part. On the other hand, java.sql.Time is a wrapper around the java.util.Date, thus internally it also may contain fractional seconds. So, when sending the java.sql.Time with ‘sendFractionalSecondsForTime=true’, its value is rendered with fractional seconds; with ‘sendFractionalSecondsForTime=false’, the value is rendered without fractional seconds.

This option is not applied to getters–values from MySQL TIME are always constructed with a fractional part if provided by server.

Connection property sendFractionalSeconds=true|false is redefined as a global switch. If set to “false”, fractional seconds are rounded or truncated not only for TIMESTAMP but also for any other date-time type.

Additional Information and Resources

MySQL Connector/J 8.0.23 has been released

Dear MySQL users,

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

This release includes the following new features and changes, also
described in more detail on

https://dev.mysql.com/doc/relnotes/connector-j/8.0/en/news-8-0-23.html

As always, we recommend that you check the “CHANGES” file in the
download archive to be aware of changes in behavior that might affect
your application.

To download MySQL Connector/J 8.0.23 GA, see the “General Availability
(GA) Releases” tab at http://dev.mysql.com/downloads/connector/j/

Enjoy!

Changes in MySQL Connector/J 8.0.23 (2021-01-18, General Availability)

Deprecation and Removal Notes

* As an implementation of the MySQL Terminology Updates (https://mysqlhighavailability.com/mysql-terminology-updates/),
connection properties and public method names have
been adjusted in the following manners:

  • Changing “master” to “source”: For example, the
    connection property queriesBeforeRetryMaster becomes
    queriesBeforeRetrySource, and the method
    isMasterConnection() becomes isSourceConnection()

  • Changing “slave” to “replica”: For example, the
    connection property allowSlavesDownConnections
    becomes allowReplicaDownConnections, and the method
    getSlaveHosts() becomes getReplicaHosts()

  • Changing “blacklist” to “blocklist”: For example,
    the connection property loadBalanceBlacklistTimeout
    becomes loadBalanceBlocklistTimeout.

Old names have been deprecated—though they are still
usable for now, they are to be removed eventually in
future releases; users are therefore encouraged to switch
to the new names.

See the MySQL Connector/J 8.0 Developer Guide
(https://dev.mysql.com/doc/connector-j/8.0/en/), the
Connector/J API documentation (generated by Javadoc), and
the MySQL Connector/J X DevAPI Reference for information
on any new property and method names.

Functionality Added or Changed

* While a java.sql.TIME instance, according to the JDBC
specification, is not supposed to contain fractional
seconds by design, because java.sql.TIME is a wrapper
around java.util.Date, it is possible to store fractional
seconds in a java.sql.TIME instance. However, when
Connector/J inserted a java.sql.TIME into the server as a
MySQL TIME value, the fractional seconds were always
truncated. To allow the fractional seconds to be sent to
the server, a new connection property,
sendFractionalSecondsForTime, has been introduced: when
the property is true (which is the default value), the
fractional seconds for java.sql.TIME are sent to the
server; otherwise, the fractional seconds are truncated.
Also, the connection property sendFractionalSeconds has
been changed into a global control for the sending of
fractional seconds for ALL date-time types. As a result,
if sendFractionalSeconds=false, fractional seconds are
not sent irrespective of the value of
sendFractionalSecondsForTime.
(Bug #20959249, Bug #76775)

* Connector/J now supports the following authentication
methods for LDAP Pluggable Authentication
(https://dev.mysql.com/doc/refman/8.0/en/ldap-pluggable-authentication.html)
with the MySQL Enterprise Server:

  • The GSSAPI/Kerberos Authentication Method:
    (https://dev.mysql.com/doc/refman/8.0/en/ldap-pluggable-authentication.html#ldap-pluggable-authentication-gssapi)
    A new connection property,
    ldapServerHostname, has been introduced for
    specifying the LDAP service host principal as
    configured in the Kerberos key distribution centre
    (KDC). See the description for ldapServerHostname in
    the MySQL Connector/J 8.0 Developer Guide
    (https://dev.mysql.com/doc/connector-j/8.0/en/) for details.

  • The SCRAM-SHA-256 method.

Bugs Fixed

* Storing a java.time.LocalDateTime object onto the server
as a TIMESTAMP value using a batched PreparedStatement
failed with the complaint that java.time.LocalDateTime
could not be cast to java.sql.Timestamp. With this fix,
the casting works again.
(Bug #32099505, Bug #101413)

* Using the setObject() method to set a
ByteArrayInputStream instance for a PreparedStatement
resulted in a SQLException. (Bug #32046007, Bug #101242)

* The returned value for a TIMESTAMP was incorrect when a
temporal interval expression
(https://dev.mysql.com/doc/refman/8.0/en/expressions.html#temporal-intervals)
was used in the SQL statement for
the query. (Bug #31074051, Bug #99013)

* After upgrading from Connector/J 5.1 to 8.0, the results
of saving and then retrieving DATETIME and TIMESTAMP
values became different sometimes. It was because while
Connector/J 5.1 does not preserve a time instant by
default, Connector/J 8.0.22 and earlier tried to so by
converting a timestamp to the server’s session time zone
before sending its value to the server. In this release,
new mechanisms for controlling timezone conversion has
been introduced—see Preserving Time Instants
(https://dev.mysql.com/doc/connector-j/8.0/en/connector-j-time-instants.html)
for details. Under this new
mechanism, the default behavior of Connector/J 5.1 in
this respect is preserved by setting the connection
property preserveInstants=false. (Bug #30962953, Bug
#98695, Bug #30573281, Bug #95644)

* Conversion of a MySQL DATETIME or TIMESTAMP value to a
Java OffsetDateTime using the getObject(i,
OffsetDateTime.class) method failed with a “Conversion
not supported for type …” error. It was because the
OffsetDateTime.parse() method on DATETIME and TIMESTAMP
values yielded an unexpected string format. With this
patch, conversions between OffsetDateTime and the DATE,
TIME, DATETIME, TIMESTAMP, and YEAR data types are now
possible, and an instant point on the timeline is
preserved as such during a conversion, when
possible—see Preserving Time Instants
(https://dev.mysql.com/doc/connector-j/8.0/en/connector-j-time-instants.html)
for details. (Bug #29402209, Bug #94457)

* When the server’s session time zone setting was not
understandable by Connector/J (for example, it was set to
CEST), a connection could not be established with the
server unless Connector/J specified the correct IANA time
zone name in the serverTimezone connection property. This
happened even if there was actually no need to use any
date-time functionality in Connector/J. The issue was
fixed by the new connection properties for Connector/J
that control date-time handling—see Preserving Time Instants
(https://dev.mysql.com/doc/connector-j/8.0/en/connector-j-time-instants.html)
for details. The following now
happens with respect to the above-mentioned situation:

  • If the new connection property connectionTimeZone is
    set to LOCAL or a specified time zone, the time_zone
    variable on the server is no longer checked

  • If connectionTimeZone=SERVER, the check for the
    time_zone variable is delayed until date-time driver
    functionality is first invoked, so that an
    unrecognizable server time zone does not prevent
    connection to be established. However, when
    date-time functionality is invoked and the value of
    time_zone cannot be recognized by Connector/J, an
    exception is thrown.

(Bug #21789378)

Enjoy and thanks for the support!

On behalf of the MySQL Release Team,
Balasubramanian Kandasamy

X DevAPI Traffic Compression With Connector/J

X Protocol traffic compression is available on MySQL Server since version 8.0.19. A connector that also supports compression on its end can leverage this feature and reduce the byte streams that are exchanged with the Server.

By default, connections to a MySQL server are uncompressed, thus permitting exchanging data with a client or connector that doesn’t support compression. However, given a client or connector that also supports compression, it is recommended that client and server negotiate the connection compression by default. If this negotiation concludes successfully, both ends can then compress the data they send.

Compression at this level allows reducing the amount of bytes exchanged over the network, but at the cost of additional CPU resources required to run data inflate and deflate operations. The benefits of compression, therefore, occur primarily on low network bandwidth. One can assess the gain or loss due to the compression only after measuring properly the average traffic sizes for a period of time for both the compressed and uncompressed connections.

Connector/J version 8.0.20 came out with basic support for traffic compression over X Protocol connections. For this purpose, a new connection option: xdevapi.compression, was introduced. As of Connector/J 8.0.22, this feature was leveled up with the introduction of two additional connection options: xdevapi.compression-extensions and xdevapi.compression-algorithms.

Let it be clear that the new compression features in the X DevAPI has no impact whatsoever on the existing compression behavior or settings of Connector/J JDBC implementation.

Continue reading

MySQL Connector/J 8.0.22 has been released

Dear MySQL users,

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

This release includes the following new features and changes, also
described in more detail on

https://dev.mysql.com/doc/relnotes/connector-j/8.0/en/news-8.0.22.html

As always, we recommend that you check the “CHANGES” file in the
download archive to be aware of changes in behavior that might affect
your application.

To download MySQL Connector/J 8.0.22 GA, see the “General Availability
(GA) Releases” tab at http://dev.mysql.com/downloads/connector/j/

Enjoy!

Changes in MySQL Connector/J 8.0.22 (2020-10-19, General
Availability)

Functionality Added or Changed


     * Security Enhancement: Previously, the LOCAL data loading
       capability for the LOAD DATA statement can be controlled on the
       client side only by enabling it for all files accessible to the
       client or by disabling it altogether, using the connection
       property allowLoadLocalInfile. A new connection property,
       allowLoadLocalInfileInPath, has been introduced to allow LOCAL
       data loading only from a specific filepath; see the description
       for the option in Configuration Properties
(https://dev.mysql.com/doc/connector-j/8.0/en/connector-j-reference-configuration-properties.html)
       for details.

     * X DevAPI: A new connection property,
       xdevapi.compression-algorithms, has been introduced for
       specifying the compression algorithms to use and the priority in
       which they will be negotiated for.  Also, the older connection
       property xdevapi.compression-algorithm (without an “s” at the end
       of its name) has been renamed to xdevapi.compression-extensions;
       its function remains the same as before (providing
       implementations for compression algorithms), but the syntax for
       its value has been changed: each element in a triplet for an
       algorithm is now separated by a colon (:). See Connection
       Compression Using X DevAPI
(https://dev.mysql.com/doc/connector-j/8.0/en/connector-j-connection-compression-xdevapi.html)
       for details.

     * X DevAPI: The asynchronous variant of the X Protocol is no
       longer supported by Connector/J; the connection properties
       useAsyncProtocol and asyncResponseTimeout are now deprecated and
       have no effect when used.

     * X DevAPI: Connector/J now supports Java keystore for SSL client
       certificates for X DevAPI sessions. The following new connection
       properties have been introduced for the purpose:

          + xdevapi.ssl-keystore

          + xdevapi.ssl-keystore-type

          + xdevapi.ssl-keystore-password
       See Connecting Securely Using SSL
(https://dev.mysql.com/doc/connector-j/8.0/en/connector-j-reference-using-ssl.html)
       for details.

     * When trying to open multiple connections to a MySQL server using
       Connector/J with a named pipe on Windows systems, the attempt
       sometimes failed with the “All pipe instances are busy” error.
       With this fix, if a timeout has been set using the connection
       property connectTimeout or the method
       DriverManager.setLoginTimeout(), Connector/J will retry opening
       the named pipe repeatedly until the timeout is reached or the
       named pipe is opened successfully. As a side-effect of this new
       behavior, there will be a delay, equal to the length of the
       timeout, for throwing an error for a failed named-pipe connection
       even when it is caused by an error other than “All pipe instances
       are busy.” (Bug #31711961, Bug #98667)

     * When the connection option sslMode is set to VERIFY_IDENTITY,
       Connector/J now validates the host name in the connection string
       against the host names or IP addresses provided under the Subject
       Alternative Name (SAN) extension in the server’s X.509
       certificate. Also, verification against the Common Name (CN) is
       now performed when a SAN is not provided in the certificate or if
       it does not contain any DNS name or IP address entries. Host
       names listed in the certificate, under either the SAN or the CN,
       can contain a wildcard character as specified in the RFC 6125
       standard. Thanks to Daniël van Eeden for contributing to the
       patch. (Bug #31443178, Bug #99767, Bug #28834903, Bug #92903)

     * When using Connector/J, the AbandonedConnectionCleanupThread
       thread can now be disabled completely by setting the new system
       property com.mysql.disableAbandonedConnectionCleanup to true when
       configuring the JVM. The feature is for well-behaving
       applications that always close all connections they create.
       Thanks to Andrey Turbanov for contributing to the new feature.
       (Bug #30304764, Bug #96870)

     * Connector/J now supports client authentication with MySQL
       Enterprise Server using simple or SASL (SCRAM-SHA-1) LDAP
       authentication
(https://dev.mysql.com/doc/refman/8.0/en/ldap-pluggable-authentication.html#ldap-pluggable-authentication-usage)
       on Windows and Linux platforms.

     * Connector/J can now be prevented from falling back to the
       system-wide truststore and keystore for server and client
       identity authentication, respectively. For JDBC connections, two
       new connection properties, fallbackToSystemKeyStore and
       fallbackToSystemTrustStore, have been introduced for the control.
       While those properties are true by default (fallbacks enabled),
       setting them to false disable fallbacks. See Connecting Securely
       Using SSL
(https://dev.mysql.com/doc/connector-j/8.0/en/connector-j-reference-using-ssl.html)
       for details.  X DevAPI: Similar
       control for fallback for X DevAPI connections are provided by
       the new connection properties,
       xdevapi.fallback-to-system-keystore, and
       xdevapi.fallback-to-system-truststore.

     * The integration classes for JBoss have been removed from
       Connector/J.

Bugs Fixed


     * In a load balancing setup, if the connection parameter
       loadBalanceBlacklistTimeout was set, a server that was once
       unavailable remained in the blocklist even after a connection to
       it has been reestablished, and this affected the system’s
       performance. With this fix, the server is removed from the
       blocklist as soon as it becomes available again. (Bug #31699357,
       Bug #96309)

     * Using a PreparedStatement to store a Date into a database
       sometimes resulted in a NullPointerException. It was
       because some assignments were missing in
       ServerPreparedQueryBindValue.clone(), and this patch
       corrects the issue. (Bug #31418928, Bug #99713)

* When a client attempted to establish a JDBC connection using the server’s X Protocol port, Connector/J threw an ArrayIndexOutOfBoundsException. With this fix, Connector/J throws the proper exception for using the wrong protocol with the port and returns a proper error message. (Bug #31083755, Bug #99076)

     * LocalDate, LocalDateTime, and LocalTime values set through
       Connector/J were altered when there was a timezone difference
       between the server and the client.  This fix corrects the issue
       by handling the LocalDate, LocalTime, and LocalDateTime with no
       time zone conversion and no intermediate conversions to other
       date-time classes. Thanks to Iwao Abe for his contribution to the
       fix. (Bug #29015453, Bug #93444)

Enjoy and thanks for the support!

On behalf of the MySQL Release Team,
Nawaz Nazeer Ahamed

MySQL Connector/J 8.0.21 has been released

Dear MySQL users,

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

In the documentation for MySQL 8.0.21, we have started
changing the term “master” to “source”, the term “slave” to
“replica”, the term “whitelist” to “allowlist”, and the term
“blacklist” to “blocklist”. There are currently no changes to
the product’s syntax, so these terms are still present in the
documentation where the current code requires their use. See
the blog post MySQL Terminology Updates
(https://mysqlhighavailability.com/mysql-terminology-updates/)
for more information.

This release includes the following new features and changes, also
described in more detail on

https://dev.mysql.com/doc/relnotes/connector-j/8.0/en/news-8-0-21.html

As always, we recommend that you check the “CHANGES” file in the
download archive to be aware of changes in behavior that might affect
your application.

To download MySQL Connector/J 8.0.21 GA, see the “General Availability
(GA) Releases” tab at http://dev.mysql.com/downloads/connector/j/

Enjoy!

Changes in MySQL Connector/J 8.0.21 (2020-07-13, General Availability)

* Functionality Added or Changed

* Bugs Fixed Functionality Added or Changed

Functionality Added or Changed

* X DevAPI: The JSON Schema Validation Functions (https://dev.mysql.com/doc/refman/8.0/en/json-validation-functions.html)
on MySQL servers are now supported by
Connector/J; see Schema Validation for details.

* The required versions of the 3rd-party libraries needed
for running or compiling Connector/J have been changed;
new requirements for additional libraries have also been
added. See Installing Connector/J from a Binary
Distribution
(https://dev.mysql.com/doc/connector-j/8.0/en/connector-j-binary-installation.html)
and Installing from Source
(https://dev.mysql.com/doc/connector-j/8.0/en/connector-j-installing-source.html) for details.

Bugs Fixed

* When trying to set a parameter for a PreparedStatement
using the method
PreparedStatement.setObject(parameterIndex, “false”,
Types.BOOLEAN), the value was set to true instead of
false. (Bug #30911870, Bug #98237)

On Behalf of MySQL Release Engineering Team,
Surabhi Bhat




MySQL Connector/J 5.1.49 GA has been released

Dear MySQL Users,

MySQL Connector/J 5.1.49, a maintenance release of the production 5.1
branch, has been released. Connector/J is the Type-IV pure-Java JDBC
driver for MySQL.

MySQL Connector/J is available in source and binary form from the
Connector/J download pages at
http://dev.mysql.com/downloads/connector/j/5.1.html
and mirror sites as well as Maven repositories.

MySQL Connector/J (Commercial) is available for download on the My Oracle
Support (MOS) website. This release will shortly be available on
eDelivery (OSDC).

As always, we recommend that you check the “CHANGES” file in the
download archive to be aware of changes in behavior that might affect
your application.

MySQL Connector/J 5.1.49 includes the following general bug fixes and
improvements, also available in more detail on
https://dev.mysql.com/doc/relnotes/connector-j/5.1/en/news-5-1-49.html

Changes in MySQL Connector/J 5.1.49 (2020-04-29, General
Availability)

   Version 5.1.49 is a maintenance release of the production 5.1
   branch. It is suitable for use with MySQL Server versions
   5.6, 5.7, and 8.0. It supports the Java Database Connectivity
   (JDBC) 4.2 API.

     * Functionality Added or Changed

     * Bugs Fixed

Functionality Added or Changed

     * Default value of the connection property
       allowLoadLocalInfile has been changed to false.
       Applications that use the LOAD DATA LOCAL INFILE
       (https://dev.mysql.com/doc/refman/8.0/en/load-data.html)
       statement on MySQL Servers need to set this property to
       true explicitly. (Bug #29261254, Bug #30866178)

     * The allowable versions of TLS protocol used for
       connecting to the server, when no restrictions have been
       set using the connection properties enabledTLSProtocols,
       have been changed to:

          + TLSv1, TLSv1.1, and TLSv1.2 for MySQL Community
            Servers 8.0, 5.7.28 and later, and 5.6.46 and later,
            and for commercial versions of MySQL Server 5.6,
            5.7, and 8.0.

          + TLSv1 and TLSv1.1 for all other versions of MySQL
            Servers.

     * The following third-party libraries have been removed
       from the distribution bundles for Connector/J:

          + C3P0 (required for building Connector/J from source)

          + JBoss common JDBC wrapper (required for building
            Connector/J from source)

          + Simple Logging Facade API (required for using the
            logging capabilities provided by the default
            implementation of org.slf4j.Logger.Slf4JLogger by
            Connector/J, and for building Connector/J from
            source)
       Users who need those libraries have to obtain them on
       their own. See Installing Connector/J from a Binary
       Distribution
(https://dev.mysql.com/doc/connector-j/5.1/en/connector-j-binary-installation.html)
       and Installing from Source
(https://dev.mysql.com/doc/connector-j/5.1/en/connector-j-installing-source.html)
       for details.

Bugs Fixed


     * When trying to set a parameter for a PreparedStatement
       using the method
       PreparedStatement.setObject(parameterIndex, “false”,
       Types.BOOLEAN), the value was set to true instead of
       false. (Bug #30911870, Bug #98237)

     * In line with good XML practices, DTD processing has been
       disabled for Connector/J’s MySQL Fabric XML parser. (Bug
       #30657312)

     * Methods of the ResultSetUtil class that are no longer
       used in Connector/J 5.1 have been removed. (Bug
       #30636056)

     * For some prepared statements, calling getMetaData() on
       them resulted in an Incorrect DATE error, even when no
       DATE values were involved. This was due to some recent
       changes on the MySQL Server, to which this patch adjusts
       Connector/J. (Bug #30151808, Bug #96442)
       References: See also: Bug #29025656, Bug #28940878.

     * When working with a load balancing setup, if the
       connection property loadBalanceStrategy was set to
       bestResponseTime and connections to all the hosts in the
       original setup failed, Connector/J hung, even if there
       were actually newly-added hosts available. This was
       because Connector/J mishandled the host whitelist, and
       this patch corrects the problem. (Bug #23143279)

     * Inserting values in batch using a PreparedStatement
       failed for an INSERT …VALUE
       (https://dev.mysql.com/doc/refman/8.0/en/insert.html)
       statement but worked for an INSERT … VALUES
       (https://dev.mysql.com/doc/refman/8.0/en/insert.html)
       statement, while they are synonymous for MySQL. (Bug
       #21181501, Bug #77183)


On Behalf of Oracle/MySQL Release Engineering Team,
Sreedhar S

MySQL Connector/J 8.0.20 has been released

Dear MySQL users,

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

This release includes the following new features and changes, also
described in more detail on

https://dev.mysql.com/doc/relnotes/connector-j/8.0/en/news-8-0-20.html

As always, we recommend that you check the “CHANGES” file in the
download archive to be aware of changes in behavior that might affect
your application.

To download MySQL Connector/J 8.0.20 GA, see the “General Availability
(GA) Releases” tab at http://dev.mysql.com/downloads/connector/j/

Enjoy!

Changes in MySQL Connector/J 8.0.20 (2020-04-27, General Availability)

* Functionality Added or Changed

* Bugs Fixed

Functionality Added or Changed

* X DevAPI: Connector/J now supports data compression for X Protocol
connections (https://dev.mysql.com/doc/refman/8.0/en/x-plugin-connection- compression.html). See Connection Compression Using X DevAPI (https://dev.mysql.com/doc/connector-j/8.0/en/connector-j-connection-compression-xdevapi.html) for details.

* A new method, getElapsedTime(), has been added to
Connector/J ‘s implementation of the Statement interface,
to expose the elapsed time for a query. Thanks to Matti
Sillanpää for contributing the code. (Bug #30570249, Bug
#97714)

Bugs Fixed

* When a custom Calendar was used in the setDate method for
a PreparedStatement, it was being used by subsequent
calls of the same method that did not use the same
calendar, resulting in the wrong date being set. It was
because the SimpleDateFormat object created internally
with the custom calendar was cached and reused. With this
fix, the object is no longer cached. (Bug #30877755)

* Setting the connection property clientInfoProvider
without using the fully qualified class name for
ClientInfoProviderSP caused a NullPointerException. This
was due to some wrong exception handling, which has been
corrected by this fix. (Bug #30832513)

* Authentication failed when a client tried to connect to a
server that used Windows Authentication Plugin and the
Kerberos protocol. It was because the implementation of
the NativeAuthenticationProvider class by Connector/J did
not interact correctly with a custom-made Kerberos
authentication plugin, and this patch fixes the issue.
(Bug #30805426)

* Methods from the ResultSetUtil class are no longer used
in Connector/J 8.0.20; the class has therefore been
removed. (Bug #30636056)

* A NullPointerException was returned when the connection
had cacheResultSetMetadata=true and a query containing
any SET statements was executed. This fix corrects the
issue by adding the missing variable assignment, and also
a null check. (Bug #30584907, Bug #97757)

* A DataConversionException was thrown when an application
tried to store a string starting with “d.” [d was any
digit] into a VARCHAR column. It was due to a parsing
error in the AbstractNumericValueFactory, which has been
fixed by this patch. Thanks to Nick Pollett for
contributing the code. (Bug #30570721, Bug #97724)

* When creating a Statement, the specification for the
resultSetType parameter was not honored, so that the
ResultSet type was always set to
ResultSet.TYPE_FORWARD_ONLY. With this fix, the
resultSetType parameter is now honored. Also, type
validation has been added so that calling the methods
beforeFirst, afterLast, first, last, absolute, relative,
or previous results in an exception if the ResultSet type
is ResultSet.TYPE_FORWARD_ONLY. (Bug #30474158)

* When a Calendar was not used, a java.sql.Date value could
not always be stored into and then retrieved from a MySQL
server consistently. It was because Connector/J always
converted a Date value to the server’s time zone when
storing it on the server as a MySQL DATE; but since a
MySQL DATE does not have any time value, the hour,
minute, and second parts of the original date was
effectively lost. If the converted value is one day ahead
of or behind the original value, when the value was
retrieved through Connector/J and converted back to the
local time zone, there was no time value for adjusting
the date back to its original value, resulting in a
one-day error. With this fix, any Date value is converted
to MySQL DATE value using the JVM’s time zone, so that
the value is always consistent when being stored and then
read back.
Also, the cacheDefaultTimezone connection property,
previously removed from Connector/J 8.0, has now been
restored so that when it is set to false, Connector/J
becomes aware of the time zone changes of the JVM during
runtime and converts dates with the updated time zone.
(Bug #28125069, Bug #91112)

On Behalf of MySQL Release Engineering Team,
Surabhi Bhat

MySQL Connector/J 8.0.19 has been released

Dear MySQL users,

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

This release includes the following new features and changes, also
described in more detail on

https://dev.mysql.com/doc/relnotes/connector-j/8.0/en/news-8-0-19.html

As always, we recommend that you check the “CHANGES” file in the
download archive to be aware of changes in behavior that might affect
your application.

To download MySQL Connector/J 8.0.19 GA, see the “General Availability
(GA) Releases” tab at http://dev.mysql.com/downloads/connector/j/

Enjoy!

Changes in MySQL Connector/J 8.0.19 (2020-01-13, General Availability)

Functionality Added or Changed


     * Connector/J now supports the use of DNS SRV records for
       connections.  Here is a brief summary for Connector/J’s support
       for DNS SRV records:

          + These new schemas in the connection URLs enable DNS
            SRV support:
               o jdbc:mysql+srv: For ordinary and basic failover
                 JDBC connections that make use of DNS SRV
                 records.
               o jdbc:mysql+srv:loadbalance: For load-balancing
                 JDBC connections that make use of DNS SRV
                 records.
               o jdbc:mysql+srv:replication: For replication
                 JDBC connections that make use of DNS SRV
                 records.
               o mysqlx+srv: For X DevAPI connections that make
                 use of DNS SRV records.

          + Besides using the new schemas in the connection
            URLs, DNS SRV record support can also be enabled or
            disabled using the two new connection properties,
            dnsSrv and xdevapi.dns-srv, for JDBC and X DevAPI
            connections respectively.
       See Support for DNS SRV Records
(https://dev.mysql.com/doc/connector-j/8.0/en/connector-j-reference-dns-srv.html)
       in the Connector/J 8.0 Developer Guide
(https://dev.mysql.com/doc/connector-j/8.0/en/) for
       details.

     * X DevAPI: The server failover support for connections
       using X DevAPI has been enhanced with the following features:

          + When the priority property is NOT set for each host
            in the connection URL, failover connections are
            attempted on the hosts in a random order, until a
            connection is successfully established (Connector/J
            used to attempt connections to the hosts in the
            sequence they appear in the connection URL).

          + Once all hosts have been tried and no connections
            can be made, Connector/J throws a
            com.mysql.cj.exceptions.CJCommunicationsException
            and returns the message Unable to connect to any of
            the target hosts.

          + When using connection pooling, Connector/J keeps
            track of any host it failed to connect to and, for a
            short waiting period after the failure, avoids
            connecting to it during the creation or retrieval of
            a Session. However, if all other hosts have already
            been tried, those excluded hosts will be retried
            without waiting. Once all hosts have been tried and
            no connections can be established, Connector/J
            throws a
            com.mysql.cj.exceptions.CJCommunicationsException
            and returns the message Unable to connect to any of
            the target hosts.

     * X DevAPI: The allowed TLS versions and cipher suites for
       X DevAPI connections can now be restricted by two new
       connection properties:

          + xdevapi.tls-versions restricts the allowable TLS
            protocol versions to be used for X DevAPI
            connections.

          + xdevapi.tls-ciphersuites restricts the allowable
            cipher suites to be used for X DevAPI connections.
       See the descriptions for them in Configuration Properties
(https://dev.mysql.com/doc/connector-j/8.0/en/connector-j-reference-configuration-properties.html)
       and also Connecting Securely Using SSL
(https://dev.mysql.com/doc/connector-j/8.0/en/connector-j-reference-using-ssl.html)
       for details.

     * MySQL Server 8.0.17 deprecated the display width for the
       TINYINT, SMALLINT, MEDIUMINT, INT, and BIGINT data types when the
       ZEROFILL modifier is not used, and MySQL Server 8.0.19 has
       removed the display width for those data types from results of
       SHOW CREATE TABLE, SHOW CREATE FUNCTION, and queries on
       INFORMATION_SCHEMA.COLUMNS, INFORMATION_SCHEMA.ROUTINES, and
       INFORMATION_SCHEMA.PARAMETERS (except for the display width for
       signed TINYINT(1)). This patch adjusts Connector/J to those
       recent changes of MySQL Server and, as a result,
       DatabaseMetaData, ParameterMetaData, and ResultSetMetaData now
       report identical results for all the above-mentioned integer
       types and also for the FLOAT and DOUBLE data types.
       (Bug #30477722)

     * The cipher suites usable by Connector/J are now
       pre-restricted by a properties file that can be found at
       src/main/resources/com/mysql/cj/TlsSettings.properties inside the
       src folder on the source tree or in the platform-independent
       distribution archive (in .tar.gz or .zip format) for Connector/J.
       See Connecting Securely Using SSL
(https://dev.mysql.com/doc/connector-j/8.0/en/connector-j-reference-using-ssl.html)
       for details.

     * The allowable versions of TLS protocol used for
       connecting to the server, when no restrictions have been set
       using the connection properties enabledTLSProtocols, have been
       changed to:

          + TLSv1, TLSv1.1, TLSv1.2, and TLSv1.3 for MySQL
            Community Servers 8.0, 5.7.28 and later, and 5.6.46
            and later, and for all commercial versions of MySQL
            Servers.

          + TLSv1 and TLSv1.1 for all other versions of MySQL
            Servers.

Bugs Fixed


     * The RPM package for Connection/J provided by the MySQL
       Yum repository did not have its epoch set; as a result, the
       package could not be installed on an Enterprise Linux or Fedora
       system even if the MySQL Yum repository has been enabled, because
       the Connector/J package in the native repository had the epoch
       set to 1. This fix sets the epoch also to 1 for the RPM package
       provided by the MySQL Yum repository, in order to prevent the
       installation problem. (Bug #30566384, Bug #97700)

     * For some prepared statements, calling getMetaData() on
       them resulted in an Incorrect DATE error, even when no DATE
       values were involved. This was due to some recent changes on the
       MySQL 8.0 Server, to which this patch adjusts Connector/J. (Bug
       #30151808, Bug #96442) References: See also: Bug #29025656,
       Bug #28940878.

     * When retrieving TIME values using
       ResultSet.getTimestamp(), the fractional seconds are truncated
       when useCursorFetch=true. This patch corrects the problem by
       fixing the TIME value decoding in the MysqlBinaryValueDecoder. It
       also corrects some inconsistencies in formatting the fractional
       seconds when returning the TIME values as strings.
       (Bug #30119545, Bug #96383)

     * Streaming of multiple result sets failed with an error.
       It was due to an error in switching the streamer source from one
       result set to another, and this fix corrects the issue.
       (Bug #29999318, Bug #96059)

Enjoy and thanks for the support!

On behalf of the MySQL Release Team,
Nawaz Nazeer Ahamed