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 …

Dear MySQL Users,

A new GA (general availability) version of MySQL Connector/C has
been made available: MySQL Connector/C 6.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/c/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.

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!

…

Dear MySQL users,

MySQL Connector/Python 2.1.5 GA is a third GA version of 2.1 release
series of the pure Python database driver for MySQL. It can be used for
production environments.

MySQL Connector/Python version 2.1.5 GA is compatible with MySQL Server
versions 5.5 and greater. Python 2.6 and greater as well as Python 3.3
and greater are supported. Python 2.4, 2.5 and 3.1, 3.2 are not
supported.

MySQL Connector/Python 2.1.5 is available for download from:

http://dev.mysql.com/downloads/connector/python/#downloads

The ChangeLog file included in the distribution contains a brief summary
of changes in MySQL Connector/Python 2.1.5. For a more complete list of
changes, see below or online at:

…

MySQL Connector/Python 2.2.2 M3 is the third 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/index.html. 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 5.7.12 or higher with the X Plugin enabled. For …

The MySQL Connector/Python Team is pleased to announce the newest MySQL Connector/Python 2.1.4, the second GA version of 2.1 release series of the pure Python database driver for MySQL.

This release includes a number of improvements for usability, stability and security.

Changes in MySQL Connector/Python 2.1.4 GA Security Notes

The linked OpenSSL library for Connector/Python Commercial has been updated to version 1.0.1q. Issues fixed in the new OpenSSL version are described at http://www.openssl.org/news/vulnerabilities.html. This change does not affect Oracle-produced MySQL Community builds of Connector/Python, which use the yaSSL library instead.
The change also does not affect connections made using any pure Python implementation of Connector/Python, for which the version of OpenSSL used is whatever is installed on the system.

Bugs fixed

• Connector/Python failed to establish connections …

The freshly released MySQL 8.0 includes a data dictionary, which makes MySQL much more reliable. Thanks to this features, we don't have any '.frm' files, and querying the information_schema is 30x to 100x faster than previous versions.

One drawback of the implementation is that the data dictionary tables are hidden by design.

While the reason is fully understandable (they don't want to commit on an interface that may change in the future) many curious users are disappointed, because openness is the basis of good understanding and feedback.

The problem to access the dictionary tables can be split in three parts:

• Finding the list of tables; …

There was a bold announcement during the MySQL Keynote at Oracle Open World. A new product that will mix up with the existing GA server, called MySQL InnoDB Cluster. This is an evolution of MySQL group replication, which has been in the labs for long time, and the MySQL shell, which was introduced as a side feature last April. The boldness I mentioned before is on account of wanting to add to a GA server something that was defined as release candidate despite never having been out of the labs. The product is interesting as it promises to be a quick and painless cluster deployment, with built-in high availability and scalability.

…

MySQL 8.0.0 was released today. It has been some time in the making, shrouded in a veil of secrecy for over one year. We knew, from listening to the gossip and looking at the few available previews, some of what was going to bring. So, for the observant users, its main features may not come as a surprise. For the rest of you, here's a quick roundup:

Notable features

• No MyISAM tables anymore! The grant tables are now InnoDB, meaning that grant operations are now atomic.
• A real data dictionary. This change is less visible than the previous one. The data dictionary tables are hidden and only a subset of the data is available through information_schema views. The reason for the hidden tables is to allow a stable interface through several versions. I am …

Starting with Vitess v2.0.0-beta.2, the VTGate V3 API can route complex single-shard queries (containing joins, subqueries, aggregation, sorting, and any combination thereof) as well as perform cross-shard joins. That means you no longer need to tell VTGate the keyspace ID that a query targets, as you did with the VTGate V2 API. The fact that keyspace IDs are now hidden from the application has enabled drop-in Vitess libraries for standard database interfaces like JDBC (written by Flipkart), PDO (written by Pixel Federation), PEP 249, and database/sql.

That means we’ve accomplished all our planned overhauls of client APIs and backward-incompatible protocol changes. See the release notes for what’s new. We’re now working closely with several users who are evaluating Vitess and providing feedback on the use cases that are important for their particular applications and production environments. If you’re at the same stage, we welcome you to join the discussion by posting on the mailing list. We’re also trying out Slack for more conversational topics.