MySQL Connectors 8.0.16 – Time to Catch up!

Posted on May 6, 2019 by Reggie Burnett

HI again! It’s been some time since I wrote and shared some of our updates with you. My intention back then was to give you an update with every release — if only all my plans worked out! However we’ve now had 3 releases since last I shared an update with you so it’s time that I updated everyone on what we’ve been working on.

All of our connectors (well except for ODBC) implement our new X DevAPI and so I’ll briefly go over these features and then break out some of the major connector specific features included.

X DevAPI

Handling of default schema

We had some inconsistencies regarding how a default schema given on a connection string was handled by some of our connectors. If a user gives a schema on the connection string — such as this – it was expected that myschema would be the default schema set on the session. This would mean that any SQL issued against that session would work against that schema. Not all connectors were handling this the correct way.

var session = mysqlx.getSession("mysqlx://localhost/myschema")

Various API standardization efforts

With many of our releases we’ll included various API standardizing efforts. We are always comparing our connectors and trying to make sure that the “core” API is essentially the same among all of them. When we see differences we schedule updates to correct those. Our goal is that if you understand the X DevAPI in one language then you can understand it in all the languages.

Prepared Statement support

With 8.0.16 we released prepared statement support when working with our X DevAPI/Document Store connectors. The first thing you may notice is that there isn’t any specific API for accessing prepared statements. This fits in with our general philosophy of letting the connectors “do the right thing” for the user rather than force the user to always write code. In this case the connector will notice that you are executing a “preparable” query more than once and will automatically make use of prepared statements for you. As of right now there is no way to configure or adjust this behavior. You should see a significant performance improvement from 8.0.15 to 8.0.16 when doing something like a loop of inserts or updates.

Connection Pooling Enhancements

An enhancement was included in 8.0.16 to improve our connection pooling by speeding how our connectors could “reset” the internal connection to the server. This is entirely an internal improvement. Developers will see this as a faster connection pool.

Connection Attributes

Connection attributes are a feature where you can pass in key value pairs when a connection is made. These values will be stored in the server performance schema and can be queried later as a way of “profiling” your application. Think of it simply as “tagging” your connections. These values can be given when the pool is created or when old style sessions are opened. Here is an example code snippet giving some connection attributes when opening an old-style session:

var session = mysqlx.getSession("mysqlx://localhost/schema
?connection-attributes=[key1=value1,key2=value2]")

Connector specific Features

Now I’d like to make a quick list of some of the larger changes we made to our connectors that are *not* connected to the X DevAPI. These are not all of the changes in our connectors. Each connector puts out a release announcement giving the entire change list with each release.

Connector/CPP
- Support for MSVC 2017
- Improved internal string handling
- Improved our CMaked-based build system
Connector/Python
- Removed support for Django versions less then 1.11
Connector/Net
- Can now use SSL certificates in the PEM file format

As always, we really appreciate your willingness to work with our products and look forward to your feedback.

MySQL Connector/Python 8.0 – A year in

Posted on May 3, 2019 by Johannes Schlüter

It’s been a year since MySQL 8.0 became GA and 8.0.16 has just been released. A good time to look at what happened with MySQL Connector/Python over the last few years.

pypi presence

When we created our connector we knew hat providing it via PyPI was important and we used PyPI as distribution channel. Later PEP 470 was published, which changed how packages are hosted and we introduced the C Extension, which required re-working the packaging. It took us a bit time to get all things right, but for a while we are now back on PyPI and you can get it not only from or downloads page, but also with a simple install using the pip tool:

$ pip install mysql-connector-python
Collecting mysql-connector-python
  Downloading https://files.pythonhosted.org/packages/d5/f9/00cfdc1604fd262adbe814c432305c4e21bbb8951bbb774062125b04c31d/mysql_connector_python-8.0.16-cp35-cp35m-manylinux1_x86_64.whl (13.0MB)
     |████████████████████████████████| 13.0MB 2.0MB/s 
Collecting protobuf>=3.0.0 (from mysql-connector-python)
  Downloading https://files.pythonhosted.org/packages/81/59/c7b0815a78fd641141f24a6ece878293eae6bf1fce40632a6ab9672346aa/protobuf-3.7.1-cp35-cp35m-manylinux1_x86_64.whl (1.2MB)
     |████████████████████████████████| 1.2MB 1.8MB/s 
Requirement already satisfied: setuptools in ./lib/python3.5/site-packages (from protobuf>=3.0.0->mysql-connector-python) (41.0.1)
Collecting six>=1.9 (from protobuf>=3.0.0->mysql-connector-python)
  Downloading https://files.pythonhosted.org/packages/73/fb/00a976f728d0d1fecfe898238ce23f502a721c0ac0ecfedb80e0d88c64e9/six-1.12.0-py2.py3-none-any.whl
Installing collected packages: six, protobuf, mysql-connector-python
Successfully installed mysql-connector-python-8.0.16 protobuf-3.7.1 six-1.12.0

$ pip install mysql-connector-python

Collecting mysql-connector-python

Downloading https://files.pythonhosted.org/packages/d5/f9/00cfdc1604fd262adbe814c432305c4e21bbb8951bbb774062125b04c31d/mysql_connector_python-8.0.16-cp35-cp35m-manylinux1_x86_64.whl (13.0MB)

|████████████████████████████████| 13.0MB 2.0MB/s

Collecting protobuf>=3.0.0 (from mysql-connector-python)

Downloading https://files.pythonhosted.org/packages/81/59/c7b0815a78fd641141f24a6ece878293eae6bf1fce40632a6ab9672346aa/protobuf-3.7.1-cp35-cp35m-manylinux1_x86_64.whl (1.2MB)

|████████████████████████████████| 1.2MB 1.8MB/s

Requirement already satisfied: setuptools in ./lib/python3.5/site-packages (from protobuf>=3.0.0->mysql-connector-python) (41.0.1)

Collecting six>=1.9 (from protobuf>=3.0.0->mysql-connector-python)

Downloading https://files.pythonhosted.org/packages/73/fb/00a976f728d0d1fecfe898238ce23f502a721c0ac0ecfedb80e0d88c64e9/six-1.12.0-py2.py3-none-any.whl

Installing collected packages: six, protobuf, mysql-connector-python

Successfully installed mysql-connector-python-8.0.16 protobuf-3.7.1 six-1.12.0

After installation, which of course also works in a virtual environment, usage is just as it had been installed using the other packages, without hurdles as dependencies like protobuf are installed automatically:

$ python
Python 3.5.2 (default, Nov 23 2017, 16:37:01) 
[GCC 5.4.0 20160609] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import mysql.connector
>>> cnx = mysql.connector.connect(user='root', database='sys')
>>> cursor = cnx.cursor()
>>> cursor.execute("SHOW TABLES")
>>> for (table_name) in cursor:
...     print(table_name)
... 
('host_summary',)
('host_summary_by_file_io',)
('host_summary_by_file_io_type',)
....

$ python

Python 3.5.2 (default, Nov 23 2017, 16:37:01)

[GCC 5.4.0 20160609] on linux

Type "help", "copyright", "credits" or "license" for more information.

>>> import mysql.connector

>>> cnx = mysql.connector.connect(user='root', database='sys')

>>> cursor = cnx.cursor()

>>> cursor.execute("SHOW TABLES")

>>> for (table_name) in cursor:

... print(table_name)

...

('host_summary',)

('host_summary_by_file_io',)

('host_summary_by_file_io_type',)

....

Making the C extension default

Initially our Connector was written in 100% Python. This gives great portability to all platforms and all Python runtime implementations. However en- and decoding the network packages and doing all the related handling can take some time. To bring you the best performance we, some while ago, introduced the C Extension, which builds around libmysql and by using C can notably improve the performance. With 8.0 we took the big step and made it the default. Thus users now automatically benefit from the performance boost, without a change to the application. If however you want to use the pure python implementation just set the use_pure option to True and the old default is back. The pure Python version is still maintained for maximum compatibility and used automatically if the C extension can’t be loaded. If the C extension is available can be easily checked:

>>> mysql.connector.HAVE_CEXT
True

1 2	>>> mysql.connector.HAVE_CEXT True

Introduction of X DevAPI and Document Store

A big change in all parts of MySQL 8.0 was the introduction of he MySQL Document Store, with a new network protocol and a new API. The MySQL Document Store allows easy access to JSON-style documents and CRUD access to tables directly from a more high-level API. Jesper gave a good introduction, so I won’t repeat it here. Of course you get the X DevAPI support as part of the PyPI package and of course the boost using the C extension is default as well.

EOL for MySQL Connector/Python 2

In January we have put the 2.1 series out of support to be able to to fully focus on 8.0. But don’t be afraid by the big jump in the version number. Version 8.0 is fully compatible. The only potential break is that we are defaulting now to the C extension as mentioned above. he only effect should be higher performance, but if that causes an issue you can go back to the pure Python version and please file a bug about why you need that.

More to come

Predictions are hard, especially about the future, but what I know for sue is, that there is a bright future for the MySQL Connector/Python. The main focus for the future is in three areas:

Making sure we give access to all the great current and upcoming features in the MySQL Server to Python users
Improve the X DevAPI to make writing new-style applications even more productive and simpler.
Improve integration into the Python ecosystem by continuing work on our Django integration and implementing different requests from the SQLAlchemy community.

Not really surprising goals, I guess. If you have any needs, please reach out to us!

MySQL Connector/ODBC 5.3.13 has been released

Posted on April 29, 2019 by MySQL Release Engineering

Dear MySQL users,

MySQL Connector/ODBC 5.3.13, 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.6.

This is the sixth 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).

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

Changes in MySQL Connector/ODBC 5.3.13 (2019-04-29, General Availability)

Bugs Fixed

* Connector/ODBC 5.3 is now built with MySQL client library
5.7.26, which includes OpenSSL 1.0.2R. Issues fixed in
the new OpenSSL version are described at
http://www.openssl.org/news/vulnerabilities.html. (Bug
#29489006)

* An exception was emitted when fetching contents of a
BLOB/TEXT records after executing a statement as a
server-side prepared statement with a bound parameter.
The workaround is not using parameters or specifying
NO_SSPS=1 in the connection string; this allows the
driver to fetch the data. (Bug #29282638, Bug #29512548,
Bug #28790708, Bug #93895, Bug #94545, Bug #92078)

On Behalf of Oracle/MySQL Release Engineering Team,
Hery Ramilison

MySQL Shell 8.0.16 for MySQL Server 8.0 and 5.7 has been released

Posted on April 25, 2019 by MySQL Release Engineering

Dear MySQL users,

MySQL Shell 8.0.16 is a maintenance release of MySQL Shell 8.0 Series (a
component of the MySQL Server). The MySQL Shell is provided under
Oracle’s dual-license.

MySQL Shell 8.0 is highly recommended for use with MySQL Server 8.0 and
5.7. Please upgrade to MySQL Shell 8.0.16.

MySQL Shell is an interactive JavaScript, Python and SQL console
interface, supporting development and administration for the MySQL
Server. It provides APIs implemented in JavaScript and Python that
enable you to work with MySQL InnoDB cluster and use MySQL as a document
store.

The AdminAPI enables you to work with MySQL InnoDB cluster, providing an
integrated solution for high availability and scalability using InnoDB
based MySQL databases, without requiring advanced MySQL expertise. For
more information about how to configure and work with MySQL InnoDB
cluster see

https://dev.mysql.com/doc/refman/en/mysql-innodb-cluster-userguide.html

The X DevAPI enables you to create “schema-less” JSON document
collections and perform Create, Update, Read, Delete (CRUD) operations
on those collections from your favorite scripting language. For more
information about how to use MySQL Shell and the MySQL Document Store
support see

https://dev.mysql.com/doc/refman/en/document-store.html

For more information about the X DevAPI see

https://dev.mysql.com/doc/x-devapi-userguide/en/

If you want to write applications that use the the CRUD based X DevAPI
you can also use the latest MySQL Connectors for your language of
choice. For more information about Connectors see

https://dev.mysql.com/doc/index-connectors.html

For more information on the APIs provided with MySQL Shell see

https://dev.mysql.com/doc/dev/mysqlsh-api-javascript/8.0/

and

https://dev.mysql.com/doc/dev/mysqlsh-api-python/8.0/

Using MySQL Shell’s SQL mode you can communicate with servers using the
legacy MySQL protocol. Additionally, MySQL Shell provides partial
compatibility with the mysql client by supporting many of the same
command line options.

For full documentation on MySQL Server, MySQL Shell and related topics,
see

https://dev.mysql.com/doc/mysql-shell/8.0/en/

For more information about how to download MySQL Shell 8.0.16, see the
“Generally Available (GA) Releases” tab at

http://dev.mysql.com/downloads/shell/

We welcome and appreciate your feedback and bug reports, see

http://bugs.mysql.com/

Enjoy and thanks for the support!

Changes in MySQL Shell 8.0.16 (2019-04-25, General Availability)

* Functionality Added or Changed

* Bugs Fixed

Functionality Added or Changed

* Important Change: Attempting to connect to an X Protocol
port, 33060 by default, using the classic MySQL protocol resulted
in the following error: ERROR 2013 (HY000): Lost connection to
MySQL server at 'reading initial communication packet', system
error: 0 This was because of differences in X Protocol and
classic MySQL protocol clients expectations on how connections
were initialized. Now, in such a situation the generated error
message is ERROR 2007 (HY000): Protocol mismatch; server version
= 11, client version = 10. If you encounter this error then you
are probably trying to use the wrong port for the protocol your
client is using. As part of this improvement the
mysqlx_enable_hello_notice system variable has been added, which
controls messages sent to classic MySQL protocol clients that try
to connect over X Protocol. When enabled, clients which do not
support X Protocol that attempt to connect to the server X
Protocol port receive an error explaining they are using the
wrong protocol. Set mysqlx_enable_hello_notice to false to permit
clients which do not recognize the hello message to still
connect.

* MySQL Shell's upgrade checker utility can now check the
configuration file (my.cnf or my.ini) for the server instance.
The utility checks for any system variables that are defined in
the configuration file but have been removed in the target MySQL
Server release, and also for any system variables that are not
defined in the configuration file and will have a different
default value in the target MySQL Server release. For these
checks, when you invoke checkForServerUpgrade(), you must provide
the file path to the configuration file. If you omit the file
path and the upgrade checker utility needs to run a check that
requires the configuration file, that check fails with a message
informing you that you must specify the file path. (Bug
#27801824, Bug #29222179)

* MySQL InnoDB cluster automatically and transparently
manages the communication protocol versions of its members,
whenever the cluster topology is changed using AdminAPI
operations. An InnoDB cluster always uses the most recent
communication protocol version that is supported by all instances
that are part of the cluster or joining it.

+ When an instance is added to, removed from, or
rejoins the cluster, or a rescan or reboot operation
is carried out on the cluster, the communication
protocol version is automatically set to a version
supported by the instance that is now at the
earliest MySQL Server version.

+ When you carry out a rolling upgrade by removing
instances from the cluster, upgrading them, and
adding them back into the cluster, the communication
protocol version is automatically upgraded when the
last remaining instance at the old MySQL Server
version is removed from the cluster prior to its
upgrade.
To see the communication protocol version in use in an
InnoDB cluster, use the Cluster.status() function with
the 'extended' option enabled. The communication protocol
version is returned in the 'GRProtocolVersion' field,
provided that the cluster has quorum and no cluster
members are unreachable.

* MySQL Shell now has a framework and commands that you can
use to set up and run reports to display live information from a
MySQL server, such as status and performance information. Reports
can be run once using the MySQL Shell \show command, or run then
refreshed continuously in a MySQL Shell session using the \watch
command. They can also be accessed as API functions in the
shell.reports object. The reporting facility supports both
built-in reports and user-defined reports. User-defined reports
can be created in the supported scripting languages JavaScript
and Python, and can be run in any MySQL Shell mode (JavaScript,
Python, or SQL), regardless of the language that the report was
written in. Reports can be saved in a folder in the MySQL Shell
configuration path and automatically loaded at startup. You can
also create a report directly in the MySQL Shell prompt. You
register a report to MySQL Shell using the shell.registerReport
method to provide information about the report and the options
and arguments that it supports. For more information, see
Reporting with MySQL Shell
(http://dev.mysql.com/doc/mysql-shell/8.0/en/mysql-shell-reporting.html).

* When running MySQL Shell in interactive mode, you can now
execute an SQL statement without switching to SQL mode and back
again afterwards. This function enables you to conveniently issue
some SQL statements in the context of a longer AdminAPI workflow
in JavaScript or Python mode. Use the \sql command immediately
followed by the SQL statement, for example:
\sql select * from sakila.actor limit 3;
The SQL statement does not need any additional quoting, and the
statement delimiter is optional. With this format, MySQL Shell
does not switch mode as it would if you entered the \sql command.
After the SQL statement has been executed, MySQL Shell remains in
JavaScript or Python mode.
You cannot use multiple line mode when you use the \sql command
with a query to execute single SQL statements while another
language is active. The command only accepts a single SQL query
on a single line.

* MySQL Shell history is now split per active language
which the command was issued under. This means that your history
now matches the active language, for example when you are running
in JavaScript mode having issued \js, the history contains the
previous JavaScript statements you issued, and when you issue
\sql to change to SQL mode your history contains the previous SQL
statements you issued. Similarly, now any history related
commands such as \history clear or \history delete are performed
on the history of the current active language. When you install
this version, any existing MySQL Shell history files are
duplicated to ensure that existing history is not lost.
Subsequent operations are then added to the language specific
history file.

* The new autoRejoinTries option enables you to configure
how many times an instance tries to rejoin a group after being
expelled. In scenarios where network glitches happen but recover
quickly, setting this option prevents you from having to manually
add the expelled instance back to the group. The autoRejoinTries
option accepts positive integer values between 0 and 2016 and the
default value is 0, which means that instances do not try to
automatically rejoin. Set the value to a valid integer to
configure the number of attempts expelled instances should make
to rejoin the group. You can pass the autoRejoinTries option to
these AdminAPI operations:

+ dba.createCluster()

+ Cluster.addInstance()

+ Cluster.setOption()

+ Cluster.setInstanceOption()
When you configure the autoRejoinTries option, it sets
the group_replication_autorejoin_tries system variable.
Passing the option to dba.createCluster(),
Cluster.addInstance() or Cluster.setInstanceOption()
configures the automatic rejoin for specific cluster
instances. Passing the option to Cluster.setOption()
configures the automatic rejoin for all cluster
instances.
For more information, see Responses to Failure Detection
and Network Partitioning
(http://dev.mysql.com/doc/refman/8.0/en/group-replication-responses-failure.html).

* When resultFormat was set to json or json/raw, every
result was being returned as a JSON document. This behavior was
expected when JSON wrapping is off (in other words the --json
command option was not used when starting MySQL Shell). Now, for
consistency reasons when JSON wrapping is off and resultFormat is
set to json or json/raw, every record is printed in a separate
document and statistics and warnings are printed in plain text.
For example if MySQL Shell is started without --json and
resultFormat=json/raw:
mysqlsh-sql> SHOW DATABASES;
{"Database":"information_schema"}
{"Database":"mysql"}
{"Database":"performance_schema"}
{"Database":"sys"}
4 rows in set (0.0035 sec)

If MySQL Shell is started with --json and with
resultFormat=json/raw:
mysqlsh-sql> SHOW DATABASES;
{
"hasData": true,
"rows": [
{
"Database": "information_schema"
},
{
"Database": "mysql"
},
{
"Database": "performance_schema"
},
{
"Database": "sys"
}
],
"executionTime": "0.0018 sec",
"affectedRowCount": 0,
"affectedItemsCount": 0,
"warningCount": 0,
"warningsCount": 0,
"warnings": [],
"info": "",
"autoIncrementValue": 0
}

* AdminAPI now reports information about the version of
MySQL running on instances. This information is available from
the following operations:

+ Cluster.status()

+ Cluster.describe()

+ Cluster.rescan()

See Checking the MySQL Version on Instances
(http://dev.mysql.com/doc/refman/8.0/en/mysql-innodb-cluster-working-
with-cluster.html#checking-version-on-instances) for
more information.

Bugs Fixed

* Removing an instance from a cluster when the instance to
be removed had no user defined for the group_replication_recovery
channel resulted in dropping users on the remaining instances of
the cluster. (Bug #29617572)

* MySQL Shell could be installed in an environment where
Python was not present, but the application has a dependency on
many standard Python modules, resulting in error messages at
startup. The RPM and Debian packages for MySQL Shell now
explicitly specify the dependency on Python. (Bug #29469201)

* The MSI file that is used by Windows Installer to install
MySQL Shell now adds the path to the application binary (mysqlsh)
to the Windows PATH environment variable, so that the application
can be started from a command prompt. (Bug #29457639)

* In the instructions to build MySQL Shell from source (the
INSTALL document), the required version of the optional V8
dependency has been updated from 3.28.71.19 to 6.7.288.46. Thanks
to Evgeniy Patlan for spotting this. (Bug #29430049, Bug #94529)

* The failoverConsistency option has been deprecated and a
new option named consistency has been added, to make it more
consistent with the target Group Replication
group_replication_consistency system variable name. The MySQL
Shell online documentation now also correctly describes all of
the values you can assign to the consistency option. (Bug
#29356599)

* The dba.configureLocalInstance() operation would remove
any section that did not start with mysqld from the provided
option file. This could remove sections such as the client
section from the option file. (Bug #29349014)

* MySQL Shell's upgrade checker utility
checkForServerUpgrade() could incorrectly report a schema
inconsistency error for a table whose name included a special
character such as a hyphen. (Bug #29346836, Bug #94303)

* When an instance with X Plugin disabled was added to an
InnoDB cluster, if the instance was later removed from the
cluster using Cluster.removeInstance() the operation failed with
LogicError "get_string(7): field is NULL". This was a regression
introduced by the fix for Bug#27677227. (Bug #29304183)

* There was an inconsistency between the behavior of
dba.checkInstanceConfiguration() and the commands to add
instances to the cluster (dba.createCluster() and
Cluster.addInstance()) regarding the localhost and loopback
address validation. In particular, a simple error was printed by
dba.checkInstanceConfiguration() but the execution of the
operation continued showing that everything was correct at the
end of the operation, while an error was issued and the execution
stopped for dba.createCluster() and Cluster.addInstance(). As
part of fixing this issue, it was decided that the existing
localhost and loopback address validations are no longer needed
and should be removed. In particular, whatever address is
specified for report_host, even if it is localhost or the
loopback address (127.0.0.1), should be allowed, because it was
explicitly specified by the user to use it. (Bug #29279941)

* The dba.rebootClusterFromCompleteOutage() operation was
not preserving the existing Group Replication configurations
previously set for the instances. In particular, the Group
Replication local address and exit state action values were being
changed. Now all settings are read at the time of rebooting the
cluster. (Bug #29265869)

* On Windows, MySQL Shell's upgrade checker utility
checkForServerUpgrade() incorrectly reported a schema
inconsistency error for partitioned tables. (Bug #29256562)

* Using either Cluster.setOption() or
Cluster.setInstanceOption() to set an option which only exists in
MySQL 8.0 on an instance running MySQL 5.7 was not being caught
correctly. (Bug #29246657)

* On Debian-based platforms (such as Ubuntu), if the
hostname resolved to 127.0.1.1 - which is the default on these
platforms - it was not possible to create a cluster using the
default settings. Now, in such situations a proper validation of
the instance is performed before creating a cluster and adding
instances to it. (Bug #29246110)

* MySQL Shell stopped unexpectedly if Python code was
running in interactive mode and threw exceptions from C++
libraries. These exceptions are now caught and translated to
Python's built-in RuntimeError exceptions. (Bug #29057116)

* The dba.checkInstanceConfiguration() operation did not
validate host restrictions for the account provided for cluster
administration, for example if the account could actually connect
to all of the instances in the cluster. In particular, now an
error is issued if the provided user account is only able to
connect through localhost. (Bug #29018457)

* When a connection is specified using key-value pairs in
MySQL Shell's shell.connect() method, the host name cannot be an
empty string. MySQL Shell now handles this situation consistently
and returns an error if the supplied host name is an empty
string. (Bug #28899522)

* InnoDB cluster configured auto_increment_increment and
auto_increment_offset on instances for clusters running in
multi-primary mode and consisting of up to 7 instances based on
the logic described at InnoDB cluster and Auto-increment
(http://dev.mysql.com/doc/refman/8.0/en/mysql-innodb-cluster-working-with-
cluster.html#mysql-innodb-cluster-auto-increment). But Group
Replication permits groups to contain up to 9 members, and
Cluster.addInstance() and Cluster.removeInstance() were not
following the logic used for other operations. Now, InnoDB
cluster uses the same logic for auto increment regardless of the
operation used and correctly handles multi-primary clusters with
more than 7 instances. (Bug #28812763)

* MySQL Shell's JSON import utility can now accept input
from FIFO special files (named pipes) when you invoke the utility
using the util.importJSON function, so you can carry out large
imports by this method without needing to put the data into a
file. (Bug #28785527)

* When you use the MySQL Shell command \help (or \h, or \?)
with a search pattern to search for help on a specific subject,
multiple help topic titles can match the pattern and be returned
as a list, to be selected by entering the command again with an
extended search pattern. With this system, it was possible for
help topics with a single-word title to be inaccessible from such
a list because there was nothing further to add to the search
pattern. To avoid this situation, the handling of multiple
matches has now been improved. If a topic title is found that
matches the given search pattern exactly (case-sensitive in the
event of multiple topic matches, and case-insensitive in the
event of no case-sensitive matches), the topic is identified as
the exact match and its help data is printed. The rest of the
topics with pattern matches in their titles are listed in a "see
also" section and can be selected by further pattern matching.
(Bug #28393119)

* MySQL Shell uses the host value of the provided
connection parameters as the target hostname used for AdminAPI
operations, namely to register the instance in the metadata (for
the dba.createCluster() and cluster.addInstance() operations).
However, the host used for the connection parameters might not
match the hostname that is used or reported by Group Replication,
which uses the value of the report_host system variable when it
is defined (in other words it is not NULL), otherwise the value
of hostname is used. Therefore, AdminAPI now follows the same
logic to register the target instance in the metadata and as the
default value for the group_replication_local_address variable on
instances, instead of using the host value from the instance
connection parameters. During this fix it was detected that when
the report_host variable was set to empty, Group Replication uses
an empty value for the host but AdminAPI (for example in commands
such as dba.checkInstanceConfiguration(),
dba.configureInstance(), dba.createCluster()) reports the
hostname as the value used which is inconsistent with the value
reported by Group Replication. An error is now issued by AdminAPI
if an empty value is set for the report_host system variable.
(Bug #28285389)

* In the event that dba.createCluster() failed and a
rollback was performed to remove the created replication
(recovery) users, the account created at localhost and any of the
ipWhitelist addresses were not being removed. The fix ensures
that the replication accounts are removed whenever a rollback
related to dba.createCluster() is performed. This work was based
on a code contribution from Bin Hong. (Bug #94182, Bug #29308037)

100

101

102

103

104

105

106

107

108

109

110

111

112

113

114

115

116

117

118

119

120

121

122

123

124

125

126

127

128

129

130

131

132

133

134

135

136

137

138

139

140

141

142

143

144

145

146

147

148

149

150

151

152

153

154

155

156

157

158

159

160

161

162

163

164

165

166

167

168

169

170

171

172

173

174

175

176

177

178

179

180

181

182

183

184

185

186

187

188

189

190

191

192

193

194

195

196

197

198

199

200

201

202

203

204

205

206

207

208

209

210

211

212

213

214

215

216

217

218

219

220

221

222

223

224

225

226

227

228

229

230

231

232

233

234

235

236

237

238

239

240

241

242

243

244

245

246

247

248

249

250

251

252

253

254

255

256

257

258

259

260

261

262

263

264

265

266

267

268

269

270

271

272

273

274

275

276

277

278

279

280

281

282

283

284

285

286

287

288

289

290

291

292

293

294

295

296

297

298

299

300

301

302

303

304

305

306

307

308

309

310

311

312

313

314

315

316

317

318

319

320

321

322

323

324

325

326

327

328

329

330

331

332

333

334

335

336

337

338

339

340

341

342

343

344

345

346

347

348

349

350

351

352

353

354

355

356

357

358

359

360

361

362

363

364

365

366

367

368

369

370

371

372

373

374

375

376

377

378

379

380

381

Changes in MySQL Shell 8.0.16 (2019-04-25, General Availability)

* Functionality Added or Changed

* Bugs Fixed

Functionality Added or Changed

* Important Change: Attempting to connect to an X Protocol

port, 33060 by default, using the classic MySQL protocol resulted

in the following error: ERROR 2013 (HY000): Lost connection to

MySQL server at 'reading initial communication packet', system

error: 0 This was because of differences in X Protocol and

classic MySQL protocol clients expectations on how connections

were initialized. Now, in such a situation the generated error

message is ERROR 2007 (HY000): Protocol mismatch; server version

= 11, client version = 10. If you encounter this error then you

are probably trying to use the wrong port for the protocol your

client is using. As part of this improvement the

mysqlx_enable_hello_notice system variable has been added, which

controls messages sent to classic MySQL protocol clients that try

to connect over X Protocol. When enabled, clients which do not

support X Protocol that attempt to connect to the server X

Protocol port receive an error explaining they are using the

wrong protocol. Set mysqlx_enable_hello_notice to false to permit

clients which do not recognize the hello message to still

connect.

* MySQL Shell's upgrade checker utility can now check the

configuration file (my.cnf or my.ini) for the server instance.

The utility checks for any system variables that are defined in

the configuration file but have been removed in the target MySQL

Server release, and also for any system variables that are not

defined in the configuration file and will have a different

default value in the target MySQL Server release. For these

checks, when you invoke checkForServerUpgrade(), you must provide

the file path to the configuration file. If you omit the file

path and the upgrade checker utility needs to run a check that

requires the configuration file, that check fails with a message

informing you that you must specify the file path. (Bug

#27801824, Bug #29222179)

* MySQL InnoDB cluster automatically and transparently

manages the communication protocol versions of its members,

whenever the cluster topology is changed using AdminAPI

operations. An InnoDB cluster always uses the most recent

communication protocol version that is supported by all instances

that are part of the cluster or joining it.

+ When an instance is added to, removed from, or

rejoins the cluster, or a rescan or reboot operation

is carried out on the cluster, the communication

protocol version is automatically set to a version

supported by the instance that is now at the

earliest MySQL Server version.

+ When you carry out a rolling upgrade by removing

instances from the cluster, upgrading them, and

adding them back into the cluster, the communication

protocol version is automatically upgraded when the

last remaining instance at the old MySQL Server

version is removed from the cluster prior to its

upgrade.

To see the communication protocol version in use in an

InnoDB cluster, use the Cluster.status() function with

the 'extended' option enabled. The communication protocol

version is returned in the 'GRProtocolVersion' field,

provided that the cluster has quorum and no cluster

members are unreachable.

* MySQL Shell now has a framework and commands that you can

use to set up and run reports to display live information from a

MySQL server, such as status and performance information. Reports

can be run once using the MySQL Shell \show command, or run then

refreshed continuously in a MySQL Shell session using the \watch

command. They can also be accessed as API functions in the

shell.reports object. The reporting facility supports both

built-in reports and user-defined reports. User-defined reports

can be created in the supported scripting languages JavaScript

and Python, and can be run in any MySQL Shell mode (JavaScript,

Python, or SQL), regardless of the language that the report was

written in. Reports can be saved in a folder in the MySQL Shell

configuration path and automatically loaded at startup. You can

also create a report directly in the MySQL Shell prompt. You

method to provide information about the report and the options

and arguments that it supports. For more information, see

Reporting with MySQL Shell

(http://dev.mysql.com/doc/mysql-shell/8.0/en/mysql-shell-reporting.html).

* When running MySQL Shell in interactive mode, you can now

execute an SQL statement without switching to SQL mode and back

again afterwards. This function enables you to conveniently issue

some SQL statements in the context of a longer AdminAPI workflow

in JavaScript or Python mode. Use the \sql command immediately

followed by the SQL statement, for example:

\sql select * from sakila.actor limit 3;

The SQL statement does not need any additional quoting, and the

statement delimiter is optional. With this format, MySQL Shell

does not switch mode as it would if you entered the \sql command.

After the SQL statement has been executed, MySQL Shell remains in

JavaScript or Python mode.

You cannot use multiple line mode when you use the \sql command

with a query to execute single SQL statements while another

language is active. The command only accepts a single SQL query

on a single line.

* MySQL Shell history is now split per active language

which the command was issued under. This means that your history

now matches the active language, for example when you are running

in JavaScript mode having issued \js, the history contains the

previous JavaScript statements you issued, and when you issue

\sql to change to SQL mode your history contains the previous SQL

statements you issued. Similarly, now any history related

commands such as \history clear or \history delete are performed

on the history of the current active language. When you install

this version, any existing MySQL Shell history files are

duplicated to ensure that existing history is not lost.

Subsequent operations are then added to the language specific

history file.

* The new autoRejoinTries option enables you to configure

how many times an instance tries to rejoin a group after being

expelled. In scenarios where network glitches happen but recover

quickly, setting this option prevents you from having to manually

add the expelled instance back to the group. The autoRejoinTries

option accepts positive integer values between 0 and 2016 and the

default value is 0, which means that instances do not try to

automatically rejoin. Set the value to a valid integer to

configure the number of attempts expelled instances should make

to rejoin the group. You can pass the autoRejoinTries option to

these AdminAPI operations:

+ dba.createCluster()

+ Cluster.addInstance()

+ Cluster.setOption()

+ Cluster.setInstanceOption()

When you configure the autoRejoinTries option, it sets

the group_replication_autorejoin_tries system variable.

Passing the option to dba.createCluster(),

Cluster.addInstance() or Cluster.setInstanceOption()

configures the automatic rejoin for specific cluster

instances. Passing the option to Cluster.setOption()

configures the automatic rejoin for all cluster

instances.

For more information, see Responses to Failure Detection

and Network Partitioning

(http://dev.mysql.com/doc/refman/8.0/en/group-replication-responses-failure.html).

* When resultFormat was set to json or json/raw, every

result was being returned as a JSON document. This behavior was

expected when JSON wrapping is off (in other words the --json

command option was not used when starting MySQL Shell). Now, for

consistency reasons when JSON wrapping is off and resultFormat is

set to json or json/raw, every record is printed in a separate

document and statistics and warnings are printed in plain text.

For example if MySQL Shell is started without --json and

resultFormat=json/raw:

mysqlsh-sql> SHOW DATABASES;

{"Database":"information_schema"}

{"Database":"mysql"}

{"Database":"performance_schema"}

{"Database":"sys"}

4 rows in set (0.0035 sec)

If MySQL Shell is started with --json and with

resultFormat=json/raw:

mysqlsh-sql> SHOW DATABASES;

{

"hasData": true,

"rows": [

{

"Database": "information_schema"

{

"Database": "mysql"

{

"Database": "performance_schema"

{

"Database": "sys"

}

"executionTime": "0.0018 sec",

"affectedRowCount": 0,

"affectedItemsCount": 0,

"warningCount": 0,

"warningsCount": 0,

"warnings": [],

"info": "",

"autoIncrementValue": 0

}

* AdminAPI now reports information about the version of

MySQL running on instances. This information is available from

the following operations:

+ Cluster.status()

+ Cluster.describe()

+ Cluster.rescan()

See Checking the MySQL Version on Instances

(http://dev.mysql.com/doc/refman/8.0/en/mysql-innodb-cluster-working-

with-cluster.html#checking-version-on-instances) for

more information.

Bugs Fixed

* Removing an instance from a cluster when the instance to

be removed had no user defined for the group_replication_recovery

channel resulted in dropping users on the remaining instances of

the cluster. (Bug #29617572)

* MySQL Shell could be installed in an environment where

Python was not present, but the application has a dependency on

many standard Python modules, resulting in error messages at

startup. The RPM and Debian packages for MySQL Shell now

explicitly specify the dependency on Python. (Bug #29469201)

* The MSI file that is used by Windows Installer to install

MySQL Shell now adds the path to the application binary (mysqlsh)

to the Windows PATH environment variable, so that the application

can be started from a command prompt. (Bug #29457639)

* In the instructions to build MySQL Shell from source (the

INSTALL document), the required version of the optional V8

dependency has been updated from 3.28.71.19 to 6.7.288.46. Thanks

to Evgeniy Patlan for spotting this. (Bug #29430049, Bug #94529)

* The failoverConsistency option has been deprecated and a

new option named consistency has been added, to make it more

consistent with the target Group Replication

group_replication_consistency system variable name. The MySQL

Shell online documentation now also correctly describes all of

the values you can assign to the consistency option. (Bug

#29356599)

* The dba.configureLocalInstance() operation would remove

any section that did not start with mysqld from the provided

option file. This could remove sections such as the client

section from the option file. (Bug #29349014)

* MySQL Shell's upgrade checker utility

checkForServerUpgrade() could incorrectly report a schema

inconsistency error for a table whose name included a special

character such as a hyphen. (Bug #29346836, Bug #94303)

* When an instance with X Plugin disabled was added to an

InnoDB cluster, if the instance was later removed from the

cluster using Cluster.removeInstance() the operation failed with

LogicError "get_string(7): field is NULL". This was a regression

introduced by the fix for Bug#27677227. (Bug #29304183)

* There was an inconsistency between the behavior of

dba.checkInstanceConfiguration() and the commands to add

instances to the cluster (dba.createCluster() and

Cluster.addInstance()) regarding the localhost and loopback

address validation. In particular, a simple error was printed by

dba.checkInstanceConfiguration() but the execution of the

operation continued showing that everything was correct at the

end of the operation, while an error was issued and the execution

stopped for dba.createCluster() and Cluster.addInstance(). As

part of fixing this issue, it was decided that the existing

localhost and loopback address validations are no longer needed

and should be removed. In particular, whatever address is

specified for report_host, even if it is localhost or the

loopback address (127.0.0.1), should be allowed, because it was

explicitly specified by the user to use it. (Bug #29279941)

* The dba.rebootClusterFromCompleteOutage() operation was

not preserving the existing Group Replication configurations

previously set for the instances. In particular, the Group

Replication local address and exit state action values were being

changed. Now all settings are read at the time of rebooting the

cluster. (Bug #29265869)

* On Windows, MySQL Shell's upgrade checker utility

checkForServerUpgrade() incorrectly reported a schema

inconsistency error for partitioned tables. (Bug #29256562)

* Using either Cluster.setOption() or

Cluster.setInstanceOption() to set an option which only exists in

MySQL 8.0 on an instance running MySQL 5.7 was not being caught

correctly. (Bug #29246657)

* On Debian-based platforms (such as Ubuntu), if the

hostname resolved to 127.0.1.1 - which is the default on these

platforms - it was not possible to create a cluster using the

default settings. Now, in such situations a proper validation of

the instance is performed before creating a cluster and adding

instances to it. (Bug #29246110)

* MySQL Shell stopped unexpectedly if Python code was

running in interactive mode and threw exceptions from C++

libraries. These exceptions are now caught and translated to

Python's built-in RuntimeError exceptions. (Bug #29057116)

* The dba.checkInstanceConfiguration() operation did not

validate host restrictions for the account provided for cluster

administration, for example if the account could actually connect

to all of the instances in the cluster. In particular, now an

error is issued if the provided user account is only able to

connect through localhost. (Bug #29018457)

* When a connection is specified using key-value pairs in

MySQL Shell's shell.connect() method, the host name cannot be an

empty string. MySQL Shell now handles this situation consistently

and returns an error if the supplied host name is an empty

string. (Bug #28899522)

* InnoDB cluster configured auto_increment_increment and

auto_increment_offset on instances for clusters running in

multi-primary mode and consisting of up to 7 instances based on

the logic described at InnoDB cluster and Auto-increment

(http://dev.mysql.com/doc/refman/8.0/en/mysql-innodb-cluster-working-with-

cluster.html#mysql-innodb-cluster-auto-increment). But Group

Replication permits groups to contain up to 9 members, and

Cluster.addInstance() and Cluster.removeInstance() were not

following the logic used for other operations. Now, InnoDB

cluster uses the same logic for auto increment regardless of the

operation used and correctly handles multi-primary clusters with

more than 7 instances. (Bug #28812763)

* MySQL Shell's JSON import utility can now accept input

from FIFO special files (named pipes) when you invoke the utility

using the util.importJSON function, so you can carry out large

imports by this method without needing to put the data into a

file. (Bug #28785527)

* When you use the MySQL Shell command \help (or \h, or \?)

with a search pattern to search for help on a specific subject,

multiple help topic titles can match the pattern and be returned

as a list, to be selected by entering the command again with an

extended search pattern. With this system, it was possible for

help topics with a single-word title to be inaccessible from such

a list because there was nothing further to add to the search

pattern. To avoid this situation, the handling of multiple

matches has now been improved. If a topic title is found that

matches the given search pattern exactly (case-sensitive in the

event of multiple topic matches, and case-insensitive in the

event of no case-sensitive matches), the topic is identified as

the exact match and its help data is printed. The rest of the

topics with pattern matches in their titles are listed in a "see

also" section and can be selected by further pattern matching.

(Bug #28393119)

* MySQL Shell uses the host value of the provided

connection parameters as the target hostname used for AdminAPI

operations, namely to register the instance in the metadata (for

the dba.createCluster() and cluster.addInstance() operations).

However, the host used for the connection parameters might not

match the hostname that is used or reported by Group Replication,

which uses the value of the report_host system variable when it

is defined (in other words it is not NULL), otherwise the value

of hostname is used. Therefore, AdminAPI now follows the same

logic to register the target instance in the metadata and as the

default value for the group_replication_local_address variable on

instances, instead of using the host value from the instance

connection parameters. During this fix it was detected that when

the report_host variable was set to empty, Group Replication uses

an empty value for the host but AdminAPI (for example in commands

such as dba.checkInstanceConfiguration(),

dba.configureInstance(), dba.createCluster()) reports the

hostname as the value used which is inconsistent with the value

reported by Group Replication. An error is now issued by AdminAPI

if an empty value is set for the report_host system variable.

(Bug #28285389)

* In the event that dba.createCluster() failed and a

rollback was performed to remove the created replication

(recovery) users, the account created at localhost and any of the

ipWhitelist addresses were not being removed. The fix ensures

that the replication accounts are removed whenever a rollback

related to dba.createCluster() is performed. This work was based

on a code contribution from Bin Hong. (Bug #94182, Bug #29308037)

On Behalf of Oracle/MySQL Release Engineering Team,
Nawaz Nazeer Ahamed

MySQL Connector/J 8.0.16 has been released

Posted on April 25, 2019 by MySQL Release Engineering

Dear MySQL users,

MySQL Connector/J Version 8.0.16 is the GA release of the 8.0
branch of MySQL Connector/J. 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-16.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.16 GA, see the “Generally Available
(GA) Releases” tab at http://dev.mysql.com/downloads/connector/j/

Enjoy!

———————————————————————–

Changes in MySQL Connector/J 8.0.16 (2019-04-25, General Availability)

Functionality Added or Changed

* X DevAPI: Added BigInteger, BigDecimal, and Character as
supported classes whose instances can be passed to a
Table as Expression instances. Also made the error
message clearer when applications try to pass instances
of unsupported classes. (Bug #25650912)

* X DevAPI: Connector/J now supports the ability to send
connection attributes
(http://dev.mysql.com/doc/refman/8.0/en/performance-schema-connection-attribute-tables.html)
(key-value pairs that application programs can pass to the
server at connect time) for X Protocol connections.
Connector/J defines a default set of attributes
(http://dev.mysql.com/doc/refman/8.0/en/performance-schema-connection-attribute-tables.html#performance-schema-connection-attributes-cj),
which can be disabled or enabled. In addition,
applications can specify attributes to be
passed in addition to the default attributes. The default
behavior is to send the default attribute set. See the
description for the new configuration property
xdevapi.connect-attributes for details.
Note
The aggregate size of connection attribute data sent by a
client is limited by the value of the
performance_schema_session_connect_attrs_size server
variable. The total size of the data package should be
less than the value of the server variable, or the
attribute data will be truncated.

* X DevAPI: When using X DevAPI, performance for statements
that are executed repeatedly (two or more times) is
improved by using server-side prepared statements for the
second and subsequent executions. See Working with
Prepared Statements
(http://dev.mysql.com/doc/x-devapi-userguide/en/working-with-prepared-statements.html)
in the X DevAPI User Guide
(http://dev.mysql.com/doc/x-devapi-userguide/en/) for details.

* The version number has been removed from the name of the
Connector/J JAR archive within the RPM packages for
Connector/J. That makes upgrading Connector/J with RPM
packages easier. (Bug #29384853)

* The collation utf8mb4_zh_0900_as_cs has been added to the
CharsetMapping class. (Bug #29244101)

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

+ Google protobuf for Java (required for using X
DevAPI and for building Connector/J from source)

+ 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
(http://dev.mysql.com/doc/connector-j/8.0/en/connector-j-binary-installation.html)
and Installing from Source
(http://dev.mysql.com/doc/connector-j/8.0/en/connector-j-installing-source.html)
for details.

Bugs Fixed

* X DevAPI: The method unquoteWorkaround() has been removed
from the ExprParser class, as the workaround is no longer
needed, and it actually produced wrong results in some
cases. (Bug #29257922)

* X DevAPI: Connector/J threw an error when a JSON document
contained only a field with an empty array as its value.
With this fix, Connector/J now takes that as a valid JSON
document. (Bug #28834959, Bug #92819)

* getByte() calls failed on table columns of the
BINARY data type. This was due to issues with string
conversion, which has been corrected with this fix. (Bug
#25650385)

* X DevAPI: Any statements sent after a failed procedure
call caused Connector/J to hang. This was because after
the failed call, Connector/J was not aware that the
result streamer had already been closed by the server.
With this fix, an error is thrown when the procedure call
fails, and the result streamer is nullified. (Bug
#22038729)

* X DevAPI: Unary negative and positive operators inside
expressions were parsed wrongly as binary minus and plus
operators. (Bug #21921956)

* Because the SHOW PROCESSLIST
(http://dev.mysql.com/doc/refman/8.0/en/show-processlist.html)
statement might cause the server to fail sometimes,
Connector/J now avoids using the statement, but queries
the performance scheme instead for the information it
needs. (Bug #29329326)

* Some unnecessary information has been removed from the
Connector/J log. (Bug #29318273)

* In the DatabaseMetaDataUsingInfoSchema interface, the
getProcedureColumns() and getFunctionColumns() methods
returned wrong results for the PRECISION column, and the
getColumns() and getVersionColumns() methods returned
wrong results for the COLUMN_SIZE column. The errors were
due to the wrong handling of the temporal type precision
by Connector/J, which has now been fixed. (Bug #29186870)

* For an SSL connection, after a client disconnected from a
server by calling Connection.close(), the TCP connection
remained in the TIME_WAIT
(http://dev.mysql.com/doc/refman/8.0/en/can-not-connect-to-server.html)
state on the server side. With this fix,
the connection remains in the TIME_WAIT
(http://dev.mysql.com/doc/refman/8.0/en/can-not-connect-to-server.html)
state on the client side instead, in most
cases. (Bug #29054329, Bug #93590)

* The function
LoadBalancedConnectionProxy.getGlobalBlacklist() always
returned an empty map, thus there was never a blacklist
for load-balanced connections. (Bug #28860051, Bug
#93007)

* The redundant file, changelog.gz, has been removed from
the Debian 9 package for Connector/J. The file repeated
the contents of the CHANGES.gz file. (Bug #27786499)

* Using getBytes() to retrieve TEXT data resulted in a
NumberFormatException. With this fix, the proper
exception (SQLDataException), is now thrown. (Bug
#27784363)

* A changeUser() call failed with a java.io.IOException
when the configuration property enablePacketDebug was set
to true for a connection. (Bug #25642021)

* bindings.getBoolean() always returned false. It was due
to a mishandling of data types, which has been corrected
with this fix. (Bug #22931700)

Enjoy and thanks for the support!

On Behalf of MySQL/ORACLE RE Team
Sreedhar S

MySQL Connector/ODBC 8.0.16 has been released

Posted on April 25, 2019 by MySQL Release Engineering

Dear MySQL users,

MySQL Connector/ODBC 8.0.16 is a new version in the MySQL Connector/ODBC 8.0 series,
the ODBC driver for the MySQL Server.

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 the latest MySQL server version 8.0.

This release of the MySQL ODBC driver is 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).

The release is now available in source and binary form for a number of platforms
from our download pages at

https://dev.mysql.com/downloads/connector/odbc/

For information on installing, please see the documentation at

https://dev.mysql.com/doc/connector-odbc/en/connector-odbc-installation.html

Enjoy and thanks for the support!

==================================================

Changes in MySQL Connector/ODBC 8.0.16 (2019-04-25, General Availability)

Bugs Fixed

* Connector/ODBC 8.0 is now built with OpenSSL 1.0.2R.
Issues fixed in the new OpenSSL version are described at
http://www.openssl.org/news/vulnerabilities.html. (Bug
#29538143)

On Behalf of Oracle/MySQL Release Engineering Team,
Hery Ramilison

MySQL Connector/NET 8.0.16 has been released

Posted on April 25, 2019 by MySQL Release Engineering

Dear MySQL users,

MySQL Connector/NET 8.0.16 is the fourth version to support
Entity Framework Core 2.1 and the sixth general availability release
of MySQL Connector/NET to add support for the new X DevAPI, which
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/index.html. For more
information about how the X DevAPI is implemented in Connector/NET, see
http://dev.mysql.com/doc/dev/connector-net. NuGet packages provide functionality at a project level. To get the
full set of features available in Connector/NET such as availability
in the GAC, integration with Visual Studio’s Entity Framework Designer
and integration with MySQL for Visual Studio, installation through
the MySQL Installer or the stand-alone MSI is required.

Please note that the X DevAPI requires at least MySQL Server version
8.0 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/8.0/en/document-store.html.

To download MySQL Connector/NET 8.0.16, see
http://dev.mysql.com/downloads/connector/net/

Installation instructions can be found at
https://dev.mysql.com/doc/connector-net/en/connector-net-installation.html

Changes in MySQL Connector/NET 8.0.16 ( 2019-04-25, General Availability )


     * Functionality Added or Changed
     * Bugs Fixed
Functionality Added or Changed
     * Document Store: Support was added for the -> operator to

       be used with JSON document paths in relational

       statements. For example:

table.Select().Where("additionalinfo->$.hobbies = 'Reading'");
       (Bug #29347028)
     * Document Store: The performance for statements that are

       executed repeatedly (two or more times) is improved by

       using server-side prepared statements for the second and

       subsequent executions. This happens internally;

       applications need take no action and API behavior should

       be the same as previously. For statements that change,

       repreparation occurs as needed. Providing different data

       values or different OFFSET or LIMIT clause values does

       not count as a change. Instead, the new values are passed

       to a new invocation of the previously prepared statement.
     * Document Store: Connector/NET now supports the ability to

       send connection attributes (key-value pairs that

       application programs can pass to the server at connect

       time). Connector/NET defines a default set of attributes,

       which can be disabled or enabled. In addition,

       applications can specify attributes to be passed together

       with the default attributes. The default behavior is to

       send the default attribute set.

       The aggregate size of connection attribute data sent by a

       client is limited by the value of the

       performance_schema_session_connect_attrs_size server

       variable. The total size of the data package should be

       less than the value of the server variable. For X DevAPI

       applications, specify connection attributes as a

       connection-attributes parameter in a connection string.

       For usage information, see Options for X Protocol Only

       (http://dev.mysql.com/doc/connector-net/en/connector-net-8-0-connection-options.html#connector-net-8-0-connection-options-xprotocol).

       For general information about connection attributes, see

       Performance Schema Connection Attribute Tables

       (http://dev.mysql.com/doc/refman/8.0/en/performance-schema-connection-attribute-tables.html).
     * Document Store: Connector/NET now has improved support

       for resetting sessions in connection pools. Returning a

       session to the pool drops session-related objects such as

       temporary tables, session variables, and transactions,

       but the connection remains open and authenticated so that

       reauthentication is not required when the session is

       reused.
     * Connector/NET applications now can use certificates in

       PEM format to validate SSL connections in addition to the

       native PFX format (see Tutorial: Using SSL with Connector/NET

       (http://dev.mysql.com/doc/connector-net/en/connector-net-tutorials-ssl.html)).

       PEM support applies to both classic MySQL protocol

       and X Protocol connections.
Bugs Fixed
     * Document Store: All methods able to execute a statement

       were unable to execute the same statement a second time.

       Now, the values and binding parameters remain available

       after the method is executed and string parameters are no

       longer converted to numbers. Both changes enable a

       follow-on execution to reuse the previous parameters.

       (Bug #29249857, Bug #29304767)
     * An exception was generated when the MySqlDbType

       enumeration was given an explicit value and then passed

       as a parameter to the MySqlCommand.Prepare method. (Bug

       #28834253, Bug #92912)
     * Validation was added to ensure that when a column is of

       type TIME and the value is 00:00:00, it takes the value

       instead of setting NULL. (Bug #28383726, Bug #91752)

On Behalf of MySQL Release Engineering Team, Surabhi Bhat

MySQL Connector/Node.js 8.0.16 has been released

Posted on April 25, 2019 by MySQL Release Engineering

Dear MySQL users,

MySQL Connector/Node.js is a new Node.js driver for use with the X
DevAPI. This release, v8.0.16, is a maintenance release of the
MySQL Connector/Node.js 8.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/.

Changes in MySQL Connector/Node.js 8.0.16 (2019-04-25, General Availability)


X DevAPI Notes
* Connector/Node.js now supports connection attributes as

key-value pairs that application programs can pass to the

server. Connector/Node.js defines a default set of

attributes, which can be disabled or enabled. In addition

to these default attributes, applications can also

provide their own set of custom attributes.
+ Specify connection attributes as a

connection-attributes parameter in a connection

string, or by using the connectionAttributes

property using either a plain JavaScript object or

JSON notation to specify the connection

configuration options.

The connection-attributes parameter value must be

either empty (the same as specifying true), a

Boolean value (true or false to enable or disable

the default attribute set), or a list of zero or

more key=value pair specifiers separated by commas

(to be sent in addition to the default attribute

set). Within a list, a missing key value evaluates

as NULL.

The connectionAttributes property allows passing

user-defined attributes to the application using

either a plain JavaScript object or JSON notation to

specify the connection configuration options. Define

each attribute in a nested object under

connectionAttributes where the property names

matches the attribute names, and the property values

match the attribute values. Unlike

connection-attributes, and while using plain

JavaScript objects or JSON notation, if the

connectionAttributes object contains duplicate keys

then no error is thrown and the last value specified

for a duplicate object key is chosen as the

effective attribute value.

Examples:

Not sending the default client-defined attributes:

mysqlx.getSession('{ "user": "root", "connectionAttributes": false }')
mysqlx.getSession('mysqlx://root@localhost?connection-attributes=false

')
mysqlx.getSession({ user: 'root', connectionAttributes: { foo: 'bar',

baz: 'qux', quux: '' } })

mysqlx.getSession('mysqlx://root@localhost?connection-attributes=[foo=

bar,baz=qux,quux]')
Application-defined attribute names cannot begin with _

because such names are reserved for internal attributes.

If connection attributes are not specified in a valid

way, an error occurs and the connection attempt fails.

For general information about connection attributes, see

Performance Schema Connection Attribute Tables

(http://dev.mysql.com/doc/refman/8.0/en/performance-schema-connection-attribute-tables.html).
Functionality Added or Changed
* Optimized the reuse of existing connections through

client.getSession() by only re-authenticating if

required.
* For X DevAPI, performance for statements that are

executed repeatedly (two or more times) is improved by

using server-side prepared statements for the second and

subsequent executions. This happens internally;

applications need take no action and API behavior should

be the same as previously. For statements that change,

repreparation occurs as needed. Providing different data

values or different offset() or limit() values does not

count as a change. Instead, the new values are passed to

a new invocation of the previously prepared statement.
Bugs Fixed
* Idle pooled connections to MySQL Server were not reused,

and instead new connections had to be recreated. (Bug

#29436892)
* Executing client.close() would not close all associated

connections in the connection pool. (Bug #29428477)
* connectTimeout instead of maxIdleTime determined whether

idle connections in the connection pool were reused

rather than creating new connections. (Bug #29427271)
* Released connections from the connection pool were not

being reset and reused; instead new connections were

being made. (Bug #29392088)
* Date values in documents were converted to empty objects

when inserted into a collection. (Bug #29179767, Bug

#93839)
* A queueTimeout value other than 0 (infinite) prevented

the acquisition of old released connections from the

connection pool. (Bug #29179372, Bug #93841)

On Behalf of MySQL/ORACLE RE Team Gipson Pulla

MySQL Connector/C++ 8.0.16 has been released

Posted on April 25, 2019 by MySQL Release Engineering

Dear MySQL users,

MySQL Connector/C++ 8.0.16 is a new release version of the MySQL Connector/C++ 8.0 series.

Connector/C++ 8.0 can be used to access MySQL implementing Document Store or in a traditional way, using SQL queries. It allows writing both C++ and plain C applications using X DevAPI and X DevAPI for C. It also supports the legacy API of Connector/C++ 1.1 based on JDBC4.

To learn more about how to write applications using X DevAPI, see “X DevAPI User Guide” at

https://dev.mysql.com/doc/x-devapi-userguide/en/

MySQL Connector/Python 8.0.16 has been released

Posted on April 25, 2019 by MySQL Release Engineering

Dear MySQL users,

MySQL Connector/Python 8.0.16 is the latest GA release version of the
MySQL Connector Python 8.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.

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 at least MySQL Server version 8.0
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/8.0/en/document-store.html.

To download MySQL Connector/Python 8.0.16, see the “General Available
(GA) releases” tab at http://dev.mysql.com/downloads/connector/python/

Enjoy!

Changes in MySQL Connector/Python 8.0.16 (2019-04-25, General
Availability)


     * Functionality Added or Changed

     * Bugs Fixed

Functionality Added or Changed


     * Two informative text files were added: INFO_BIN contains
       information about the build environment used to produce
       the distribution, and INFO_SRC provides information about
       the product version and the source repository from which
       the distribution was produced. (Bug #29454706)

     * Django 1.11 is now the minimum supported Django version.

     * For X DevAPI applications, Connector/Python now supports
       the ability to send connection attributes (key-value
       pairs that application programs can pass to the server at
       connect time). Connector/Python defines a default set of
       attributes, which can be disabled or enabled. In
       addition, applications can specify attributes to be
       passed in addition to the default attributes. The default
       behavior is to send the default attribute set.
       For X DevAPI applications, specify connection attributes
       as a connection-attributes parameter in a connection
       string, or setting connection-attributes as a dictionary
       inside the connection settings parameter under the
       connection-attributes key. Both the mysqlx.get_session()
       and mysqlx.get_client() methods can receive this
       information.
       The connection-attributes parameter value must be empty
       (the same as specifying true), a Boolean value (true or
       false to enable or disable the default attribute set), or
       a list or zero or more key=value specifiers separated by
       commas (to be sent in addition to the default attribute
       set). Within a list, a missing key value evaluates as an
       empty string. An example connection string:
mysqlx://user:password@host:33060/schema?connection-attributes=[foo=bar,baz=qux,quux]

       Application-defined attribute names cannot begin with _
       because such names are reserved for internal attributes.
       If connection attributes are not specified in a valid
       way, an error occurs and the connection attempt fails.
       For general information about connection attributes, see
       Performance Schema Connection Attribute Tables
(http://dev.mysql.com/doc/refman/8.0/en/performance-schema-connection-attribute-tables.html).

     * Connector/Python now has improved support for resetting
       sessions in connection pools. Returning a session to the
       pool drops session-related objects such as temporary
       tables, session variables, and transactions, but the
       connection remains open and authenticated so that
       reauthentication is not required when the session is
       reused.

     * Protobuf was updated to Protobuf 3.6.1.

     * For X DevAPI, performance for statements that are
       executed repeatedly (two or more times) is improved by
       using server-side prepared statements for the second and
       subsequent executions. This happens internally;
       applications need take no action and API behavior should
       be the same as previously. For statements that change,
       repreparation occurs as needed. Providing different data
       values or different offset() or limit() values does not
       count as a change. Instead, the new values are passed to
       a new invocation of the previously prepared statement.

Bugs Fixed


     * Added a "username" alias for the "user" connection
       argument. Thanks to Matthew Woods for the patch. (Bug
       #29324966, Bug #94248)

     * Solaris 11 package files had the expected owner/group set
       as pb2user/common instead of root/bin. (Bug #29278489)

     * CRUD operations would not allow referencing a renamed
       column (AS SomeLabel) from the fetched result. (Bug
       #29001628)

     * Fixed a memory corruption issue that caused an unexpected
       halt when fetching fields. (Bug #28479054)

     * Querying an empty LONG BLOB raised an IndexError
       exception. (Bug #27897881, Bug #90519)

Changes in MySQL Connector/Python 8.0.16 (2019-04-25, General

Availability)

* Functionality Added or Changed

* Bugs Fixed

Functionality Added or Changed

* Two informative text files were added: INFO_BIN contains

information about the build environment used to produce

the distribution, and INFO_SRC provides information about

the product version and the source repository from which

the distribution was produced. (Bug #29454706)

* Django 1.11 is now the minimum supported Django version.

* For X DevAPI applications, Connector/Python now supports

the ability to send connection attributes (key-value

pairs that application programs can pass to the server at

connect time). Connector/Python defines a default set of

attributes, which can be disabled or enabled. In

addition, applications can specify attributes to be

passed in addition to the default attributes. The default

behavior is to send the default attribute set.

For X DevAPI applications, specify connection attributes

as a connection-attributes parameter in a connection

string, or setting connection-attributes as a dictionary

inside the connection settings parameter under the

connection-attributes key. Both the mysqlx.get_session()

and mysqlx.get_client() methods can receive this

information.

The connection-attributes parameter value must be empty

(the same as specifying true), a Boolean value (true or

false to enable or disable the default attribute set), or

a list or zero or more key=value specifiers separated by

commas (to be sent in addition to the default attribute

set). Within a list, a missing key value evaluates as an

empty string. An example connection string:

mysqlx://user:password@host:33060/schema?connection-attributes=[foo=bar,baz=qux,quux]

Application-defined attribute names cannot begin with _

because such names are reserved for internal attributes.

If connection attributes are not specified in a valid

way, an error occurs and the connection attempt fails.

For general information about connection attributes, see

Performance Schema Connection Attribute Tables

(http://dev.mysql.com/doc/refman/8.0/en/performance-schema-connection-attribute-tables.html).

* Connector/Python now has improved support for resetting

sessions in connection pools. Returning a session to the

pool drops session-related objects such as temporary

tables, session variables, and transactions, but the

connection remains open and authenticated so that

reauthentication is not required when the session is

reused.

* Protobuf was updated to Protobuf 3.6.1.

* For X DevAPI, performance for statements that are

executed repeatedly (two or more times) is improved by

using server-side prepared statements for the second and

subsequent executions. This happens internally;

applications need take no action and API behavior should

be the same as previously. For statements that change,

repreparation occurs as needed. Providing different data

values or different offset() or limit() values does not

count as a change. Instead, the new values are passed to

a new invocation of the previously prepared statement.

Bugs Fixed

* Added a "username" alias for the "user" connection

argument. Thanks to Matthew Woods for the patch. (Bug

#29324966, Bug #94248)

* Solaris 11 package files had the expected owner/group set

as pb2user/common instead of root/bin. (Bug #29278489)

* CRUD operations would not allow referencing a renamed

column (AS SomeLabel) from the fetched result. (Bug

#29001628)

* Fixed a memory corruption issue that caused an unexpected

halt when fetching fields. (Bug #28479054)

* Querying an empty LONG BLOB raised an IndexError

exception. (Bug #27897881, Bug #90519)

Enjoy and thanks for the support!

On Behalf of Oracle/MySQL Release Engineering Team,
Balasubramanian Kandasamy

InsideMySQL.com

Latest news and insight directly from MySQL Engineering

MySQL Connectors 8.0.16 – Time to Catch up!

X DevAPI

Various API standardization efforts

Prepared Statement support

Connection Pooling Enhancements

Connection Attributes

Connector specific Features

MySQL Connector/Python 8.0 – A year in

pypi presence

Making the C extension default

Introduction of X DevAPI and Document Store

EOL for MySQL Connector/Python 2

More to come

MySQL Connector/ODBC 5.3.13 has been released

MySQL Shell 8.0.16 for MySQL Server 8.0 and 5.7 has been released

MySQL Connector/J 8.0.16 has been released

MySQL Connector/ODBC 8.0.16 has been released

MySQL Connector/NET 8.0.16 has been released

MySQL Connector/Node.js 8.0.16 has been released

MySQL Connector/C++ 8.0.16 has been released

MySQL Connector/Python 8.0.16 has been released