MySQL Connector/J 5.1.47 GA has been released

--------------FCBD0E3A9D16790CAB39410B
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit

Dear MySQL Users,

MySQL Connector/J 5.1.47, 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-2 repositories.

MySQL Connector/J (Commercial) is already 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.47 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-47.html


Changes in MySQL Connector/J 5.1.47 (2018-08-17, General Availability)

    Version 5.1.47 is a maintenance release of the production 5.1 branch.
It is suitable for use with MySQL Server versions 5.5, 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


      * The value UTF-8 for the connection property
        characterEncoding now maps to the utf8mb4 character set
        on the server and, for MySQL Server 5.5.2 and later,
        characterEncoding=UTF-8 can now be used to set the
        connection character set to utf8mb4 even if
        character_set_server has been set to something else on
        the server. (Before this change, the server must have
        character_set_server=utf8mb4 for Connector/J to use that
        character set.)
        Also, if the connection property connectionCollation is
        also set and is incompatible with the value of
        characterEncoding, characterEncoding will be overridden
        with the encoding corresponding to connectionCollation.
        See Using Character Sets and Unicode
        (http://dev.mysql.com/doc/connector-j/5.1/en/connector-j- 
<http://dev.mysql.com/doc/connector-j/5.1/en/connector-j-reference-charsets.html>reference-charsets.html 
<http://dev.mysql.com/doc/connector-j/5.1/en/connector-j-reference-charsets.html>)
        for details, including how to use the utf8mb3 character
        set now for connection. (Bug#23227334, Bug #81196)

Bugs Fixed


      * Setting rewriteBatchedStatements=true and
        useLocalTransactionState=true caused transactions to be
        uncommitted for batched UPDATE and DELETE statements. It
        was due to the intermediate queries for enabling
        multiquery support on the server resetting the local
        transaction state as a side effect. With this fix, the
        local transaction state is preserved when the
        intermediate queries are executed. (Bug #27658489, Bug
        #89948)

      * Rewriting prepared INSERT statements in a multiquery
        batch failed with a BatchUpdateException when the
        statements did not contain place holders. This was due a
        faulty mechanism for query rewriting, which has been
        corrected by this fix. (Bug #25501750, Bug #84813)

      * When using batched prepared statements with multiple
        queries per statement, queries rewriting was incorrect,
        resulting in the wrong queries being sent to the server.
        (Bug #23098159, Bug #81063)

      * ResultSet.updateRow() failed when the character set used
        by a column in the ResultSet did not match that of the
        connection's encoding. With this fix, values for the
        affected columns are first converted to String before the
        update, so that the character set difference is properly
        handled. (Bug #22847443, Bug #80532)

      * Record updates failed for a scrollable and updatable
        PreparedStatement when the WHERE clause for the updater
        or refresher contained fractional timestamp values and
        the connection property sendFractionalSeconds was set to
        false. It was because in the situation, Connector/J did
        not perform the proper adjustments of the fractional
        parts in the WHERE clause values according to the length
        of the field's fractional part as defined in the
        database. This fix makes Connector/J perform the proper
        adjustment to the fractional part, so that the WHERE
        clause value can be properly compared to the value
        fetched from the database.
        Moreover, useJDBCCompliantTimezoneShift(),
        useGmtMillisForDatetimes(), and
        useSSPSCompatibleTimezoneShift() were applied to the
        WHERE clause values while they should not be, and this
        fix removes their applications. (Bug #22305979)

      * When a Java Date value was bound to a PreparedStatement
        parameter, attempts to format the value by a proleptic
        GregorianCalendar failed to make the dates proleptic, so
        that dates before the Julian-Gregorian cutover (October
        15, 1582) were stored wrongly. With this fix, a proleptic
        calendar is properly used if supplied to the setDate()
        method.
        Note that when trying to set or retrieve dates before the
        Julian-Gregorian cutover with PreparedSatement methods, a
        proleptic GregorianCalendar should always be explicitly
        supplied to the setDate() and getDate() method.For
        details, see Known Issues and Limitations
        
(http://dev.mysql.com/doc/connector-j/5.1/en/connector-j-usagenotes-known-issues-limitations.html).
(Bug#18749544, Bug #72609)


On Behalf of MySQL Release Engineering Team,
Surabhi Bhat


--------------FCBD0E3A9D16790CAB39410B--