Simplified Client and Connector Versioning

Here at MySQL we are constantly improving both our servers and our client software by making things simple to use and understand.  An area where we want to simplify things is around the version number we use for various MySQL client, connector, and other applications like Workbench, MySQL Enterprise Backup, etc.

Basically:

  • We want to make sure our users easily know which version of a connector or client works with which server version(s).
  • We want to deliver support for new server features during the server DMR phase without disrupting the GA versions of the connectors.

Which Connector Version To Use?

MySQL connectors (our client libraries — Connector/C, Connector/J, Connector/Net, etc) and other clients (tools and applications — MySQL Shell, MySQL Enterprise Backup, etc) will generally release more often than the server.  Relative to upgrading a set of servers in an enterprise, upgrading a client is normally quite simple.

Because of this rapid versioning of clients we have historically not tied the client version to the server version.  In addition to that we’ve changed the server versioning as of MySQL 8.0 to increment just the first digit for each major release.  After 8 comes 9, etc.

So you may see that the current versions of some client libraries are all over the place – 6.9 for Connector/Net, 5.1 for Connector/J, 2.1 for Connector/Python, or 4.1 for MySQL Enterprise Backup.  As you can see these version numbers do not relate to the server version at all.  We think this is confusing and with the recent server version change we could simplify things for clients, connectors, and applications.

Note:  In some cases we tried to make this easier by having a policy that all our support client libraries must support all servers that are still supported, but then there are other clients like MySQL Enterprise Manager where that’s not the case.

Challenges – DMRs and Testing Out New Server Features

The server team provides pre-release versions of the server available for testing out new features.  These releases are called DMR or “Development Milestone Release”.  While many of the new server features are transparent to client libraries, some require client library updates like new collations or new security measures.

When server changes affect clients users ask how can they try out the new features?   What connector or client version should they use?

And, features appearing in server DMR releases can change.  They are, after all, in development so adding support for pre-release features that can change into a GA connector is really a no-go.  So we need a  way to make new server features available to connectors and clients without disrupting the normal feature cycle of the clients.

Solving – New Simplified Versioning Methods for Clients

To address these issues beginning with the 8.0 server GA release, all of our connectors will synchronize the first digit of their version number with the server.   This means that MySQL Server 8.0 will go GA alongside 8.0 versions of each of our connectors.

Now, it’s easy to know which version of a client you should use – the first version number should match (starting with 8.x.x releases).

  • For Connectors – Using MySQL 8.0 then any of our MySQL connectors 8.0 or later will fit the bill!  Does this mean that older connectors will not work with MySQL 8.0?  Not necessarily!  However, older connectors might not be quite as compatible and will certainly not support many of the new features.
  • Other client tools and application – Will also go to 8.0 versions – MySQL Shell 8.0, MySQL Workbench 8.0, MySQL Enterprise Backup 8.0, etc.

As new MySQL Server DMR releases come out you can expect to see corresponding clients to help you try out the new features in both the client and the server.

We see the change as an opportunity to really clarify our product offerings using the version number and deliver a much more unified experience.  Clients will still version frequently so you’ll see some clients move ahead with 8.1 and 8.2 versions but that first digit 8 will still tell  you that it will work perfectly with MySQL Server 8.0

We’ll have more to say on this in the coming weeks!  Please let us know if you have any questions!

MySQL Connector/NET 6.10.2 beta has been released

Dear MySQL users,

MySQL Connector/Net 6.10.2 beta is the third release which supports Scaffold-DbContext, that enables the creation of corresponding model classes from an existing database that are compatible with Entity Framework (EF) Core 1.1.

To download MySQL Connector/Net 6.10.2 beta, see the “Development Releases” tab at http://dev.mysql.com/downloads/connector/net/

Changes in MySQL Connector/Net 6.10.2 (2017-07-04, Beta)

Functionality Added or Changed

* The previously deprecated Old Syntax (OldSyntax, Use Old Syntax, UseOldSyntax) connection-string option was removed.

* EF Core: Tables from an existing database can be specified with command-line tools when scaffolding a DbContext. The MySQL provider generates an entity type for each table in the DbContext. By default, all tables in the database are included unless a list of tables is provided.

For Package Manager Console Tools, use the Scaffold-DbContext command with the -Table <tablename, tablename, …> common parameter.

For .NET Core CLI Tools, use the dotnet ef dbcontext scaffold command with the
–table option for each table to add.

* EF Core: The MySQL provider now creates a new schema when the entity.ToTable method within a derived DbContext class specifies the name of a nonexistent schema.

* EF Core: The Connector/Net implementation of EF Core now includes extended maximum lengths for several string data types to enable the use of longer strings.

* Connector/Net no longer supports MySQL Fabric.

Bugs Fixed

* EF Core: The –force option when used with the dotnet ef dbcontext scaffold command did not overwrite the existing output files as expected. (Bug #25493508)

* EF Core: The Database First command used to create a DbContext class emitted an error when used with either the sakila or world database sample. (Bug #25493336)

* EF Core: The Database First feature did not support the following data types: BINARY, VARBINARY, MEDIUMBLOB, LONGBLOB, SET, DATE, TIME, and YEAR. (Bug #25493209)

* EF Core: JSON data exchange format was not supported by the Database First feature. (Bug #25493143)

* EF Core: Database First support produced an error when the existing MySQL database included one or more views. (Bug #25493086)

* EF Core: Using System.ComponentModel.DataAnnotations.Schema.TableAttribute to initialize a new class instance that specified the name of an existing MySQL table produced incorrect mappings of table and column names. (Bug #25394223, Bug #84423)

Nuget packages are available at:

https://www.nuget.org/packages/MySql.Data/6.10.2-beta https://www.nuget.org/packages/MySql.Web/6.10.2-beta https://www.nuget.org/packages/MySql.Data.EntityFrameworkCore/6.10.2-beta https://www.nuget.org/packages/MySql.Data.EntityFrameworkCore.Design/6.10.2-beta

Enjoy and thanks for the support!

On behalf of the MySQL Release Team,
Nawaz Nazeer Ahamed

MySQL Connector/C++ 1.1.9 has been released

Dear MySQL Users,

A new GA (general availability) version of MySQL Connector/C++ has
been made available: MySQL Connector/C++ 1.1.9 GA. The MySQL
Connector/C++ provides a C++ API for connecting client applications to
the MySQL Server 5.5 or newer.

You can download the production release at:

http://dev.mysql.com/downloads/connector/cpp/1.1.html

MySQL Connector C++ (Commercial) will be available for download on the
My Oracle Support (MOS) website. This release will be available on eDelivery
(OSDC) in next month’s upload cycle.

The MySQL driver for C++ offers an easy to use API derived from JDBC
4.0. MySQL Workbench has used it successfully for years.

We have improved the driver since the last GA release. Please see the
documentation and the CHANGES file in the source distribution for a
detailed description of bugs that have been fixed. Bug descriptions are
also listed below.

Enjoy!

Changes in MySQL Connector/C++ 1.1.9 (2017-05-16, General Availability)

Compilation Notes

* The Windows version of Connector/C++ Community is now
built using the dynamic C++ runtime library (that is, with the
/MD compiler option), with the following implications for users:

+ Target hosts running Windows applications that use
Connector/C++ Community now need the Visual C++
Redistributable for Visual Studio 2013
(https://www.microsoft.com/en-us/download/details.aspx?id=40784)
installed on them.

+ Client applications on Windows that use Connector/C++
Community should be compiled with the /MD compiler option.

Security Notes

* The linked OpenSSL library for Connector/C++ 1.1.9
Commercial has been updated to version 1.0.2k. For a description
of issues fixed in this version, see
http://www.openssl.org/news/vulnerabilities.html
This change does not affect the Oracle-produced MySQL Community
build of Connector/C++, which uses the yaSSL library instead.

Bugs Fixed

* Values returned by getDouble() from DOUBLE table columns
were truncated (decimal part missing) if the locale was set to
fr_CA, which uses comma as the decimal separator. (Bug
#17227390, Bug #69719)

* Connections to localhost failed if the local server was
bound only to its IPv6 interface. (Bug #17050354, Bug #69663)

On Behalf of the MySQL/ORACLE RE Team
Balasubramanian Kandasamy

MySQL Connector/ODBC 5.3.8 has been released

Dear MySQL users,

MySQL Connector/ODBC 5.3.8, a new version of the ODBC driver for the MySQL database management system, has been released.

The available downloads include both a Unicode driver and an ANSI driver based on the same modern codebase. Please select the driver type you need based on the type of your application – Unicode or ANSI.
Server-side prepared statements are enabled by default. It is suitable for use with any MySQL version from 5.5.

This is the fourth release of the MySQL ODBC driver conforming to the ODBC 3.8 specification. It contains implementations of key 3.8 features,
including self-identification as a ODBC 3.8 driver, streaming of output parameters (supported for binary types only), and support of the SQL_ATTR_RESET_CONNECTION connection attribute (for the Unicode driver only).

Also, Connector/ODBC 5.3 introduces a GTK+-based setup library providing a GUI DSN setup dialog on some Unix-based systems, currently included in the Debian 7/8, EL6/OL6, EL7/OL7 (64-bit only), Fedora 24/25,
FreeBSD 10/11, SLES 12, Ubuntu 12/14/16 packages. Other new features in the 5.3 driver are FileDSN and Bookmarks support.

The release is now available in source and binary form for a number of platforms from our download pages at http://dev.mysql.com/downloads/connector/odbc/5.3.html For information on installing, please see the documentation at http://dev.mysql.com/doc/connector-odbc/en/connector-odbc-installation.html Enjoy!

The MySQL Connectors team at Oracle Changes in MySQL Connector/ODBC 5.3.8 (2017-04-28)

Security Notes

* Security Fix: The linked OpenSSL library for Connector/ODBC Commercial 5.3.8 has been updated from version 1.0.2j to version 1.0.2k. Versions of OpenSSL prior to 1.0.2k are reported to be vulnerable to 2017-3731
(http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-3731), CVE-2017-3732
(http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-3732), and CVE-2017-7055
(http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-7055).
This change does not affect the Oracle-produced MySQL Community build of Connector/ODBC 5.3.8, which uses the yaSSL library instead. (Bug #25615448, CVE-2017-3731,
CVE-2017-3732, CVE-2017-7055)

Bugs Fixed

* When error 2006 (“MySQL server has gone away”) occurred,
Connector/ODBC wrongly returned the SQL_NO_DATA error.
(Bug #25671389)

* When the SQL_TIMESTAMP_STRUCT was used, if the date portion of a timestamp was populated but the time portion was uninitialized, queries involving the timestamp would fail with a Date overflow error. With this fix, the uninitialized time value is simply ignored. (Bug
#25386024)

* Segmentation faults occurred when catalog, column, or table names that were too long were passed as arguments to metadata functions like SQLColumnPrivileges(),SQLColumns(),SQLTablePrivileges()
and SQLTables(). With this fix, proper errors are returned in those cases. (Bug #18796005)

* An assertion error occurred when calling SQLSetDescField() with SQL_DESC_COUNT as FieldIdentifier,
irrespective of the record number set. (Bug #18641633)

* Connector/ODBC quit unexpectedly when a negative column number was passed as an argument for the SQLGetData()
method. (Bug #18636600)

* When server-side prepared statements were enabled, using the prefetch option caused SQL syntax errors to be returned for queries that contained parameter markers.
(Bug #17386788)

* After the attribute SQL_ATTR_MAX_ROWS had been set for a certain statement handler, a new statement handler also had the same value set automatically. The fix makes sure a new statement handler returns all rows by default. (Bug
#17259397, Bug #69554)

* If the NO_INFORMATION_SCHEMA connection option was set,
the SQLTables() function did not return the catalog correctly when a wildcard or SQL_ALL_CATALOGS was used in its arguments. (Bug #14005343)
References: See also: Bug #13914518.

On behalf of the Oracle MySQL RE Team,
Hery Ramilison

MySQL Connector/C 6.1.10 GA has been released

Dear MySQL Users,

A new GA (general availability) version of MySQL Connector/C has been
made available: MySQL Connector/C 6.1.10 GA. The MySQL Connector/C 6.1
implements the MySQL C API for connecting client applications to the
MySQL Server 5.5 or newer.

You can download the production release at:
http://dev.mysql.com/downloads/connector/c/6.1.html

MySQL Connector C (Commercial) will be available for download on the My
Oracle Support (MOS) website. This release will be available on
eDelivery (OSDC) in next month’s upload cycle.

Please see the documentation and the README file in the source distribution
for a detailed description of bugs that have been fixed.

Enjoy!

Changes in MySQL Connector/C 6.1.10 (2017-04-28, General
Availability)

Compilation Notes

* The Windows version of MySQL Connector/C Community is now
built using the dynamic C runtime libraries (that is,
with the /MD compiler option), with the following
implications for users:

+ Target hosts running Windows applications that use
MySQL Connector/C Community now need the Visual C++
Redistributable for Visual Studio 2015
(https://www.microsoft.com/en-us/download/details.aspx?id=48145)
installed on them.

+ Client applications on Windows that use MySQL
Connector/C Community should be compiled with the
/MD compiler option.

Security Notes

* The linked OpenSSL library for MySQL Connector/C 6.1
Commercial has been updated to version 1.0.2k. For a description
of issues fixed in this version, see
http://www.openssl.org/news/vulnerabilities.html. This change
does not affect the Oracle-produced MySQL Community build of
Connector/C, which uses the yaSSL library instead. (Bug
#25615447)

On behalf of the Oracle MySQL Release Engineering Team,
Nawaz Nazeer Ahamed

MySQL Connector/J 5.1.42 has been released

Link

Dear MySQL Users,

MySQL Connector/J 5.1.42, 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 Java 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 Java (Commercial) is already available for download on the
My Oracle Support (MOS) website. This release will be available on eDelivery
(OSDC) in next month’s upload cycle.

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.42 includes the following general bug fixes and
improvements, also available in more detail on
http://dev.mysql.com/doc/relnotes/connector-j/en/news-5-1-41.html

Changes in MySQL Connector/J 5.1.42 (2017-04-28)

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

* Functionality Added or Changed

* Bugs Fixed

Functionality Added or Changed

* A null value can now be extracted from a result set to a
class belonging to the java.time package. Before, such an
extraction resulted in a NullPointerException being
thrown. Thanks to Martin Desharnais for contributing the
code. (Bug #25250938, Bug #84189)

* Connector/J now checks that a MySQL server’s SSL
certificate and the Certificate Authority (CA) that
issued it are not expired before establishing an SSL
connection with the server, even if the connection
property verifyServerCertificate is set to false. (Bug
#20515688)

* Name-value pairs contained in the connection property
sessionVariables can now be separated by either commas or
a semicolons. (Bug #17757070)

Bugs Fixed

* An invalid timezone identifier was used in
StatementRegressionTest.java of the Connector/J
testsuite. (Bug #25687718, Bug #85351)

* A mysql client failed to establish an SSL connection to
the server using the SSL certificates provided in the
Connector/J source package. It was because the
certificates have been generated with the same Common
Name. This fix corrects the Common Names and regenerates
the SSL certificates. (Bug #25636947)

* The unit test testsuite.simple.ResultSetTest.testPadding
failed with the error Unknown character set: ‘gb18030’
after the collation map updates in release 5.1.40. (Bug
#25556597)

* In a multi-host connection, query timeouts did not occur
as configured. It was because the CancelTask thread, when
trying to access the top level, virtual connection
object, ran into a race condition with the connection
monitor and then hung. With this fix, the CancelTask
thread is passed a direct reference to the underlying
physical connection, with which it can execute the
cancellation. (Bug #25490163, Bug #84783)

* CallableStatement.extractProcedureName() did not return
the correct result when the procedure name contained a
dash. This was due to an error in the stripComments()
method of the StringUtils class, which has now been
corrected. (Bug #25321524, Bug #84324)

* The ConnectionImpl.isReadOnly() method returned a
confusing error message when it could not retrieve the
read-only status of the server. The message has now been
changed to “Could not retrieve transaction read-only
status from server.” (Bug #25101890, Bug #83834)

* A NullPointerException was thrown when a null boolean
value was being read from the database. (Bug #25048406,
Bug #83662)

* After a BIT value had been retrieved from a result set,
the wasNull() method of the result set returned value for
the last wasNull() query instead of the value for the
last retrieved column. (Bug #24841670, Bug #83368)

* Using a partially-quoted identifier (with only the
database or the procedure name quoted) or a non-existent
parameter to register an output parameter in a
CallableStatement caused a NullPointerException. With
this fix, a partially-quoted identifier is accepted, and
a non-existent parameter causes a SQLError to be thrown.
(Bug #22333996, Bug #79561)

* DatabaseMetaData.getProcedureColumns() and
DatabaseMetaData.getFunctionColumns() did not return
expected results. This was due to the errors with the
matching algorithm for the column names, which have now
been fixed. Notice that, however, the effects of the
connection parameter getProceduresReturnsFunctions on the
two methods when JDBC 4 is used remain unchanged. (Bug
#19531384, Bug #73775)

* When an UpdatableResultSet was used, trying to close the
result set and its prepared statement simultaneously by
different threads might result in a deadlock. This fix
updates the synchronization mechanism for
UpdatableResultSet to avoid the issue. (Bug #17653733,
Bug #70704)

* After a connection had already switched catalog with
setCatalog(), cached data from the old catalog was
returned for a reused server-side prepared statement.
With this fix, the cache of a server-side prepared
statement cache now includes the catalog in its key to
avoid wrong cache hits when the statement is reused on
another catalog. (Bug #16714868, Bug #66430)

On Behalf of MySQL/ORACLE RE Team
Gipson Pulla

MySQL Connector/Python 2.2.3 m4 Development Release has been released

MySQL Connector/Python 2.2.3 M4 is the fourth development release of the MySQL Connector Python 2.2 series. This series adds support for the new X DevAPI. The X DevAPI enables application developers to write code that combines the strengths of the relational and document models using a modern, NoSQL-like syntax that does not assume previous experience writing traditional SQL.

To learn more about how to write applications using the X DevAPI, see http://dev.mysql.com/doc/x-devapi-userguide/en/. For more information about how the X DevAPI is implemented in MySQL Connector/Python, and its usage, see http://dev.mysql.com/doc/dev/connector-python.

Please note that the X DevAPI requires MySQL Server version 5.7.12 or higher with the X Plugin enabled. For general documentation about how to get started using MySQL as a document store, see http://dev.mysql.com/doc/refman/5.7/en/document-store.html.

To download MySQL Connector/Python 2.2.3 M4, see the “Development Releases” tab at http://dev.mysql.com/downloads/connector/python/

Enjoy!

Changes in MySQL Connector/Python 2.2.3 (2017-03-22, Milestone 3)

Functionality Added or Changed

* Connector/Python now supports IPv6 target hosts in X DevAPI connection strings.

Bugs Fixed

* The defined_as(statement) method used to create views did not permit a SelectStatement object argument (generated by Table.select()). (Bug #25614860)

* The SelectStatement object returned by Table.select() failed to provide the order_by() method. (Bug #25519251)

* The pure Python implemention of Protobuf has been replaced by a C++ extension. This enables Connector/Python to support Python 2 and 3 as well as Protobuf 2 and 3. (Bug #25209469)

* import mysqlx caused an error with Python 2.6 on Solaris and EL6 platforms. (Bug #24578507)

* The error message for get_session() failure was incorrect. (Bug #23636962)

* The Collection.find() method failed to work with the LIKE operator or aggregate functions. The Collection.find() method failed to work with several
operators. Support was added for these operators:

+ Nullary Operators: *

+ Unary Operators: !, NOT, +, -, ~

+ Binary Operators: AND, &&, OR, ||, XOR, <>, ^, IS NOT, NOT REGEXP, NOT LIKE, CAST, NOT IN

+ Ternary Operators: NOT BETWEEN

In addition, arrow notation to access JSON columns is now functional (for example, schema.table.column->’$.document field’). (Bug #23567724, Bug #23568207, Bug #25436568, Bug #84585)

Documentation
——————–

Online: http://dev.mysql.com/doc/connector-python/en/index.html
The source distribution includes the manual in various formats under the docs/ folder.

Reporting Bugs
——————–

We welcome and appreciate your feedback and bug reports:
http://bugs.mysql.com/

On Behalf of the MySQL/ORACLE RE Team,
Piotr Obrzut

MySQL Connector/C++ 2.0.4 m2 has been released

MySQL Connector/C++ 2.0.4 is the next development milestone of the MySQL

Connector/C++ 2.0 series. Connector/C++ 2.0 can be used to access MySQL
implementing Document Store or in a traditional way, using SQL queries. It
allows writing both C++ applications using X DevAPI or plain C applications
using XAPI.

To learn more about how to write applications using X DevAPI, see X
DevAPI User Guide (http://dev.mysql.com/doc/x-devapi-userguide/en/) and X
DevAPI reference at
https://dev.mysql.com/doc/dev/connector-cpp/devapi_ref.html. For more
information about using plain C XAPI see XAPI reference at
http://dev.mysql.com/doc/dev/connector-cpp/xapi_ref.html. For generic
information on using Connector/C++ 2.0, see
http://dev.mysql.com/doc/dev/connector-cpp/.

Note

Connector/C++ 2.0 requires MySQL Server version 5.7.12 or higher
with X Plugin enabled. For general documentation about how to get
started using MySQL as a document store, see Using MySQL as a Document
Store (http://dev.mysql.com/doc/refman/5.7/en/document-store.html).

To download MySQL Connector/C++ 2.0.4, see the “Development Releases”
tab at http://dev.mysql.com/downloads/connector/cpp/

Changes in MySQL Connector/C++ 2.0.4 (2017-03-21, Development
Milestone)

Functionality Added or Changed

  • Support was added for secure sessions over TLS
    connections. A secure session can be requested either via
    the ssl-enable and ssl-ca options of a connection string,
    or using explicit session creation options. For X DevAPI
    session settings, see http://dev.mysql.com/doc/dev/connector-cpp/classmysqlx_1_1_session_settings.html.
    For XAPI session settings, see
    http://dev.mysql.com/doc/dev/connector-cpp/group__xapi.html
    (check the documentation for enum mysqlx_opt_type_t).
  • The format of document ID values generated when adding
    documents to a collation has changed. It is still a
    string of 32 hexadecimal digits based on UUID, but the
    order of digits was changed to match the requirement of a
    stable ID prefix.
  • The X DevAPI Schema object now supports methods for view
    manipulation: createView(), alterView(), and dropView().
    XAPI now contains functions that implement similar
    functionality: mysqlx_view_create(),
    mysqlx_view_replace(), mysqlx_view_modify(), and
    (implemented previously) mysqlx_view_drop().
    As with other XAPI operations, there are functions that
    create a statement handle without executing it:
    mysqlx_view_create_new(), mysqlx_view_replace_new(), and
    mysqlx_view_modify_new().
    These XAPI functions modify view DDL statements before
    execution: mysqlx_set_view_algorithm(),
    mysqlx_set_view_security(),
    mysqlx_set_view_check_option(),
    mysqlx_set_view_definer(), and mysqlx_set_view_columns().
  • Connector/C++ now supports IPv6 target hosts in
    connection strings and when creating sessions using other
    methods.

Bugs Fixed

  • When rList is an empty list, table.insert().rows(rList)
    caused a segmentation fault. (Bug #25515964)

On Behalf of the MySQL/ORACLE RE Team

MySQL Connector/NodeJS 1.0.6 M5 has been released

MySQL Connector/Node.js is a new Node.js driver for use with the X DevAPI. This release, v1.0.6 M5, is the fourth development release of the MySQL Connector/Node.js 1.0 series.

The X DevAPI enables application developers to write code that combines the strengths of the relational and document models using a modern, NoSQL-like syntax that does not assume previous experience writing traditional SQL.

MySQL Connector/Node.js can be downloaded through npm (see https://www.npmjs.com/package/@mysql/xdevapi for details) or from https://dev.mysql.com/downloads/connector/nodejs/.

To learn more about how to write applications using the X DevAPI, see http://dev.mysql.com/doc/x-devapi-userguide/en/. For more information about how the X DevAPI is implemented in MySQL Connector/Node.js, and its usage, see http://dev.mysql.com/doc/dev/connector-nodejs/.

Note

Please note that the X DevAPI requires at least MySQL Server version 5.7.12 or higher with the X Plugin enabled. For general documentation about how to get started using MySQL as a document store, see http://dev.mysql.com/doc/refman/5.7/en/document-store.html.

Functionality Added or Changed

  • Added support for validating the server certificate with
    a given CA and/or CRL.
  • Added support for creating TLS sessions with a URI or
    connection string.
  • Added support for creating IPv6 sessions with a URI or
    connection string.
  • Added support for single array or multiple argument
    function calls on the public API.

Bugs Fixed

  • Fixed issues with collection.bind(). (Bug #23236379)
  • Fixed parsing issues on URI and connection string
    corner-cases.
  • Updated behavior of collection.add([]) to avoid confusing
    exceptions.

Enjoy and thanks for the support!

On behalf of the MySQL/Oracle Release Engineering Team
Lars Tangvald

MySQL Connector/J 5.1.41 has been released

Dear MySQL Users,

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

Version 5.1.41 is suitable for use with many MySQL server versions,
including 4.1, 5.0, 5.1, 5.4 and 5.5.

MySQL Connector Java 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 Java (Commercial) is already available for download on the
My Oracle Support (MOS) website. This release will be available on eDelivery
(OSDC) in next month’s upload cycle.

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.41 includes the following general bug fixes and
improvements, also available in more detail on
http://dev.mysql.com/doc/relnotes/connector-j/en/news-5-1-41.html

Changes in MySQL Connector/J 5.1.41 (2017-02-28)

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

Bugs Fixed

* Connections failed with MySQLSyntaxErrorException:
Unknown character set when
connectionCollation=ISO-8859-13. This was due to a wrong
logic in Connector/J’s internal charset mapping, which
has now been fixed. (Bug #25504578)

* When loading classes through some external class loaders,
com.mysql.jdbc.Util threw an NoClassDefFoundError. This
was caused by Class.getPackage() returning null when some
external class loaders were used. This fix replaces those
calls of Class.getPackage() with calls of the new method
Class.getName(), which return package names that are
extracted from the fully-qualified class names. (Bug
#25048543, Bug #83052)

* In the manifest for the Connector/J JAR file, the
Import-Package directive specified version numbers for
the javax.net.ssl package. The specification was
unnecessary, and it caused the configuration of an SSL
connection to a MySQL server to fail in an OSGi
environment. The version requirement has now been
removed. (Bug #24942672, Bug #82826)

* In a Fabric setup, when multiple threads required to have
hashes computed, an ArrayIndexOutOfBoundsException might
be thrown from inside HashShardMapping. This fix prevents
the issue by having
HashShardMapping.getShardIndexForKey() synchronized. (Bug
#24289730, Bug #82203)

* When the configuration property cacheResultSetMetadata
was set to true, a ping query using a PreparedStatement
failed with a NullPointerException. This fix moves the
ping query to an earlier stage of the statement
execution, which prevents the exception. (Bug #23535001,
Bug #81706)

* The setFabricShardTable() method failed to parse
qualified table names (in the format of
database_name.table_name), which causes SQLExceptions to
be thrown. (Bug #23264511, Bug #81108)

* A race condition occurred when a call of
Connection.setNetworkTimeout() was followed closely by a
call of Connection.close(), and a NullPointerException
might result if the connection was closed before the
executor supplied to setNetworkTimeout() was able to set
the timeout, as the executor would run into a null
mysqlConnection object. This fix removed the race
condition. (Bug #21181249, Bug #75615)

* With the connection properties
cacheServerConfiguration=true and
elideSetAutoCommits=true, any new connection to the
server obtained after the first connection was
established had the variable autoCommit equaled false,
even if the value of the variable was true on the server.
That was because the value of autoCommit was not properly
initialized when a new connection was established, and
this fix corrects that.
Also, since release 5.1.41, the functionality of the
property elideSetAutoCommits has been disabled due to
Bug# 66884. Any value given for the property is now
ignored by Connector/J. (Bug #17756825, Bug #70785)

* When using Tomcat and a web application that utilized
Connector/J was down, Tomcat was unable to stop the
AbandonedConnectionCleanupThread started internally by
Connector/J, leading to multiple instances of the thread
when the web application was restarted; or, Tomcat was
able to stop the thread but unable to restart it on
reload of the web application. Different combinations of
Tomcat’s default settings, usage of Tomcat’s
ServletContextListener feature, and locations of the
Connector/J jar could result in the undesired behaviors,
as well as warning messages in the Tomcat error log
saying it was unable to stop the thread and a memory leak
was likely.
The implementation of AbandonedConnectionCleanupThread
has now been improved, so that there are now four ways
for developers to deal with the situation:

+ When the default Tomcat configuration is used and
the Connector/J jar is put into a local library
directory, the new built-in application detector in
Connector/J now detects the stopping of the web
application within 5 seconds and kills
AbandonedConnectionCleanupThread. Any unnecessary
warnings about the thread being unstoppable are also
avoided. If the Connector/J jar is put into a global
library directory, the thread is left running until
the JVM is unloaded.

+ When Tomcat’s context is configured with the
attribute clearReferencesStopThreads=”true”, Tomcat
is going to stop all spawned threads when the
application stops unless Connector/J is being shared
with other web applications, in which case
Connector/J is now protected against an
inappropriate stop by Tomcat; the warning about the
non-stoppable thread is still issued into Tomcat’s
error log.

+ When a ServletContextListener is implemented within
each web application that calls
AbandonedConnectionCleanupThread.checkedShutdown()
on context destruction, Connector/J now, again,
skips this operation if the driver is potentially
shared with other applications. No warning about the
thread being unstoppable is issued to Tomcat’s error
log in this case.

+ When
AbandonedConnectionCleanupThread.uncheckedShutdown()
is called, the AbandonedConnectionCleanupThread is
closed even if Connector/J is shared with other
applications. However, it may not be possible to
restart the thread afterwards.
(Bug #17035755, Bug #69526)
References: See also: Bug #14570236, Bug #16443387.

On Behalf of MySQL/ORACLE RE Team
Gipson Pulla