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

Posted on by

Dear MySQL users,

MySQL Shell 8.0.21 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.21.

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 and InnoDB
ReplicaSet, providing integrated solutions 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 and MySQL InnoDB ReplicaSet 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.21, see the
“General Availability (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.21 (2020-07-13, General Availability)

     * AdminAPI Added or Changed Functionality
     * AdminAPI Bugs Fixed
     * Functionality Added or Changed
     * Bugs Fixed

AdminAPI Added or Changed Functionality

     * A new user configurable tag framework has been added to
       the metadata, to allow specific instances of a cluster or
       ReplicaSet to be marked with additional information. Tags
       can be any ASCII character and provide a namespace. You
       set tags for an instance using the setInstanceOption()
       operation. In addition, AdminAPI and MySQL Router 8.0.21
       support specific tags, which enable you to mark instances
       as hidden and remove them from routing. MySQL Router then
       excludes such tagged instances from the routing
       destination candidates list. This enables you to safely
       take a server instance offline, so that applications and
       MySQL Router ignore it, for example while you perform
       maintenance tasks, such as server upgrade or
       configuration changes. To bring the instance back online,
       use the setInstanceOption() operation to remove the tags
       and MySQL Router adds the instance back to the routing
       destination candidates list, and it becomes online for
       applications. For more information, see Tagging the
       Metadata
(https://dev.mysql.com/doc/refman/8.0/en/admin-api-tagging.html).

AdminAPI Bugs Fixed

     * Important Change: Previously, Group Replication did not
       support binary log checksums, and therefore one of the
       requirements for instances in InnoDB cluster was that
       binary log checksums were disabled by having the
       binlog_checksum system variable set to NONE. AdminAPI
       verified the value of binlog_checksum during the
       dba.checkInstanceConfiguration() operation and disallowed
       creating a cluster or adding an instance to a cluster
       that did not have binary log checksums disabled. In
       version 8.0.21, Group Replication has lifted this
       restriction, therefore InnoDB cluster now permits
       instances to use binary log checksums, with
       binlog_checksum set to CRC32. The setting for
       binlog_checksum does not have to be the same for all
       instances. In addition, sandboxes deployed with version
       8.0.21 and later do not set the binlog_checksum variable,
       which defaults to CRC32. (Bug #31329024)

     * Adopting a Group Replication setup as a cluster can be
       performed when connected to any member of the group,
       regardless of whether it is a primary or a secondary.
       However, when a secondary member was used,
       super_read_only was being incorrectly disabled on that
       instance. Now, all operations performed during an
       adoption are done using the primary member of the group.
       This ensures that no GTID inconsistencies occur and that
       super_read_only is not incorrectly disabled on secondary
       members. (Bug #31238233)

     * Using the clusterAdmin option to create a user which had
       a netmask as part of the host resulted in an error when
       this user was passed to the dba.createCluster()
       operation. Now, accounts that specify a netmask are
       treated as accounts with wildcards, meaning that further
       checks to verify if the account accepts remote
       connections from all instances are skipped. (Bug
       #31018091)

     * The check for instance read-only compatibility was using
       a wrong MySQL version as the base version. The
       cross-version policies were added to Group Replication in
       version 8.0.17, but the check was considering instances
       running 8.0.16. This resulted in a misleading warning
       message indicating that the added instance was read-only
       compatible with the cluster, when this was not true (only
       for instances 8.0.16). The fix ensures that the check to
       verify if an instance is read-compatible or not with a
       cluster is only performed if the target instance is
       running version 8.0.17 or later. (Bug #30896344)

     * The maximum number of instances in an InnoDB cluster is
       9, but AdminAPI was not preventing you from trying to add
       more instances to a cluster and the resulting error
       message was not clear. Now, if a cluster has 9 instances,
       Cluster.addInstance prevents you adding more instances.
       (Bug #30885157)

     * Adding an instance with a compatible GTID set to a InnoDB
       cluster or InnoDB ReplicaSet on which provisioning is
       required should not require any interaction, because this
       is considered a safe operation. Previously, in such a
       scenario, when MySQL Clone was supported MySQL Shell
       still prompted to choose between cloning or aborting the
       operation. Now, the operation proceeds with cloning,
       because this is the only way to provision the instance.
       Note
       instances with an empty GTID set are not considered to
       have a compatible GTID set when compared with the InnoDB
       cluster or InnoDB ReplicaSet. Such scenarios are
       considered to be unknown, therefore MySQL Shell prompts
       to confirm which action should be taken.
       (Bug #30884590)

     * The Group Replication system variables (prefixed with
       group_replication) do not exist if the plugin has not
       been loaded. Even if the system variables are persisted
       to the instance’s option file, they are not loaded unless
       the Group Replication plugin is also loaded when the
       server starts. If the Group Replication plugin is
       installed after the server starts, the option file is not
       reloaded, so all system variables have default values.
       Instances running MySQL 8.0 do not have a problem because
       SET PERSIST is used. However, on instances running
       version MySQL 5.7, the dba.rebootCluster() operation
       could not restore some system variables if the Group
       Replication plugin was uninstalled. Now, the
       dba.configureInstance() operation persists the Group
       Replication system variables to configuration files with
       the loose_ prefix. As a result, once the Group
       Replication plugin is installed, on instances running 5.7
       the persisted values are used instead of the default
       values. (Bug #30768504)

     * The updateTopologyMode option has been deprecated and the
       behavior of Cluster.rescan() has been changed to always
       update the topology mode in the Metadata when a change is
       detected. MySQL Shell now displays a message whenever
       such a change is detected. (Bug #29330769)

     * The cluster.addInstance() and cluster.rejoinInstance()
       operations were not checking for the full range of
       settings which are required for an instance to be valid
       for adding to the cluster. This resulted in attempts to
       use instances which run on different operating systems to
       fail. For example, a cluster running on two instances
       that were hosted on a Linux based operating system would
       block the addition of an instance running Microsoft
       Windows. Now, cluster.addInstance() and
       cluster.rejoinInstance() operations validate the instance
       and prevent adding or rejoining an instance to the
       cluster if the value of the lower_case_table_names,
       group_replication_gtid_assignment_block_size or
       default_table_encryption of the instance are different
       from the ones on the cluster. (Bug #29255212)

Functionality Added or Changed

     * MySQL Shell now has an instance dump utility,
       dumpInstance(), and schema dump utility, dumpSchemas().
       The new utilities support the export of all schemas or a
       selected schema from an on-premise MySQL server instance
       into an Oracle Cloud Infrastructure Object Storage bucket
       or a set of local files. The schemas can then be imported
       into a MySQL Database Service DB System using MySQL
       Shell’s new dump loading utility. The new utilities
       provide Oracle Cloud Infrastructure Object Storage
       streaming, MySQL Database Service compatibility checks
       and modifications, parallel dumping with multiple
       threads, and file compression.

     * MySQL Shell’s new dump loading utility, loadDump(),
       supports the import of schemas dumped using MySQL Shell’s
       new instance dump utility and schema dump utility into a
       MySQL Database Service DB System. The dump loading
       utility provides data streaming from remote storage,
       parallel loading of tables or table chunks, progress
       state tracking, resume and reset capability, and the
       option of concurrent loading while the dump is taking
       place.

     * The X DevAPI implementation now supports JSON schema
       validation, which enables you to ensure that your
       documents have a certain structure before they can be
       inserted or updated in a collection. To enable or modify
       JSON schema validation you pass in a JSON object like:
{
    validation: {
      level: “off|strict”,
      schema: “json-schema”
    }
}

       Here, validation is JSON object which contains the keys
       you can use to configure JSON schema validation. The
       first key is level, which can take the value strict or
       off. The second key, schema, is a JSON schema, as defined
       at http://json-schema.org. If the level key is set to
       strict, documents are validated against the json-schema
       when they are added to the collection, or when an
       operation updates the document. If the document does not
       validate, the server generates an error and the operation
       fails. If the level key is set to off, documents are not
       validated against the json-schema.
       You can pass a validation JSON object to the
       schema.createCollection() operation, to enable JSON
       schema validation, and schema.modifyCollection()
       operation, to change the current JSON schema validation,
       for example to disable validation. For more information,
       see JSON Schema Validation
(https://dev.mysql.com/doc/x-devapi-userguide/en/collection-validation.html).

Bugs Fixed

     * MySQL Shell plugins now support the use of the **kwargs
       syntax in functions defined in Python that are made
       available by the plugin. Using **kwargs in a function
       definition lets you call the function using a
       variable-length list of keyword arguments with arbitrary
       names. If the function is called from MySQL Shell’s
       JavaScript mode, MySQL Shell passes the named arguments
       and their values into a dictionary object for the Python
       function. MySQL Shell first tries to associate a keyword
       argument passed to a function with any corresponding
       keyword parameter that the function defines, and if there
       is none, the keyword argument is automatically included
       in the **kwargs list. As a side effect of this support,
       any API function called from Python in MySQL Shell that
       has a dictionary of options as the last parameter
       supports defining these options using named arguments.
       (Bug #31495448)

     * When switching to SQL mode, MySQL Shell queries the SQL
       mode of the connected server to establish whether the
       ANSI_QUOTES mode is enabled. Previously, MySQL Shell
       could not proceed if it did not receive a result set in
       response to the query. The absence of a result is now
       handled appropriately. (Bug #31418783, Bug #99728)

     * In SQL mode, when the results of a query are to be
       printed in table format, MySQL Shell buffers the result
       set before printing, in order to identify the correct
       column widths for the table. With very large result sets,
       it was possible for this practice to cause an out of
       memory error. MySQL Shell now buffers a maximum of 1000
       rows for a result set before proceeding to format and
       print the table. Note that if a field in a row after the
       first 1000 rows contains a longer value than previously
       seen in that column in the result set, the table
       formatting will be misaligned for that row. (Bug
       #31304711)

     * Context switching in MySQL Shell’s SQL mode has been
       refactored and simplified to remove SQL syntax errors
       that could be returned when running script files using
       the source command. (Bug #31175790, Bug #31197312, Bug
       #99303)

     * The user account that is used to run MySQL Shell’s
       upgrade checker utility checkForServerUpgrade()
       previously required ALL privileges. The user account now
       requires only the RELOAD, PROCESS, and SELECT privileges.
       (Bug #31085098)

     * In Python mode, MySQL Shell did not handle invalid UTF-8
       sequences in strings returned by queries. (Bug #31083617)

     * MySQL Shell’s parallel table import utility importTable()
       has a new option characterSet, which specifies a
       character set encoding with which the input data file is
       interpreted during the import. Setting the option to
       binary means that no conversion is done during the
       import. When you omit this option, the import uses the
       character set specified by the character_set_database
       system variable to interpret the input data file. (Bug
       #31057707)

     * On Windows, if the MySQL Shell package was extracted to
       and used from a directory whose name contained multi-byte
       characters, MySQL Shell was unable to start. MySQL Shell
       now handles directory names with multi-byte characters
       correctly, including when setting up Python, loading
       prompt themes, and accessing credential helpers. (Bug
       #31056783)

     * MySQL Shell’s JSON import utility importJSON() now
       handles UTF-8 encoded files that include a BOM (byte mark
       order) at the start, which is the sequence 0xEF 0xBB
       0xBF. As a workaround in earlier releases, remove this
       byte sequence, which is not needed. (Bug #30993547, Bug
       #98836)

     * When the output format was set to JSON, MySQL Shell’s
       upgrade checker utility checkForServerUpgrade() included
       a description and documentation link for a check even if
       no issues were found. These are now omitted from the
       output, as they are with the text output format. (Bug
       #30950035)

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

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

Posted on by

Dear MySQL users,

MySQL Shell 8.0.20 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.20.

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 and InnoDB
ReplicaSet, providing integrated solutions 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 and MySQL InnoDB ReplicaSet 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.20, see the
“General Availability (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.20 (2020-04-27, General Availability)

     * AdminAPI Added or Changed Functionality

     * AdminAPI Bugs Fixed

     * Functionality Added or Changed

     * Bugs Fixed

AdminAPI Added or Changed Functionality

     * MySQL Shell now enables you to create and configure the
       MySQL user accounts required by InnoDB cluster, InnoDB
       ReplicaSet, and MySQL Router using AdminAPI operations.
       Previously, accounts required by InnoDB cluster and
       InnoDB ReplicaSet had to be configured using the
       clusterAdmin option, and accounts required by MySQL
       Router had to be configured manually using SQL. The
       following AdminAPI operations are now available:

          + use Cluster.setupAdminAccount(user, [options]) and
            Replicaset.setupAdminAccount(user, [options]) to
            configure a MySQL user account with the necessary
            privileges to administer an InnoDB cluster or InnoDB
            ReplicaSet.

          + use Cluster.setupRouterAccount(user, [options]) and
            Replicaset.setupRouterAccount(user, [options]) to
            create a MySQL user account or upgrade an existing
            account so that it that can be used by MySQL Router
            to operate on an InnoDB cluster or InnoDB
            ReplicaSet. This is now the recommended method of
            adding MySQL Router accounts to use with InnoDB
            cluster and InnoDB ReplicaSet.

     * AdminAPI now uses a locking mechanism to avoid different
       operations from performing changes on an InnoDB
       ReplicaSet simultaneously. Previously, different
       instances of MySQL Shell could connect to an InnoDB
       ReplicaSet at the same time and execute AdminAPI
       operations simultaneously. This could lead to
       inconsistent instance states and errors, for example if
       ReplicaSet.addInstance() and ReplicaSet.setPrimary() were
       executed in parallel.
       Now, the InnoDB ReplicaSet operations have the following
       locking:

          + dba.upgradeMetadata() and dba.createReplicaSet() are
            globally exclusive operations. This means that if
            MySQL Shell executes these operations on an InnoDB
            ReplicaSet, no other operations can be executed
            against the InnoDB ReplicaSet or any of its
            instances.

          + ReplicaSet.forcePrimaryInstance() and
            ReplicaSet.setPrimaryInstance() are operations that
            change the primary. This means that if MySQL Shell
            executes these operations against an InnoDB
            ReplicaSet, no other operations which change the
            primary, or instance change operations can be
            executed until the first operation completes.

          + ReplicaSet.addInstance(),
            ReplicaSet.rejoinInstance(), and
            ReplicaSet.removeInstance() are operations that
            change an instance. This means that if MySQL Shell
            executes these operations on an instance, the
            instance is locked for any further instance change
            operations. However, this lock is only at the
            instance level and multiple instances in an InnoDB
            ReplicaSet can each execute one of this type of
            operation simultaneously. In other words, at most
            one instance change operation can be executed at a
            time, per instance in the InnoDB ReplicaSet.

          + dba.getReplicaSet() and ReplicaSet.status() are
            InnoDB ReplicaSet read operations and do not require
            any locking.
       References: See also: Bug #30349849.

     * Use the –replicaset option to configure MySQL Shell to
       work with an InnoDB ReplicaSet at start up. You must
       specify a connection to a replica set instance for this
       option to work correctly. If a replica set is found, this
       option populates the rs global object, which can then be
       used to work with the InnoDB ReplicaSet. As part of this
       addition, the –redirect-primary and –redirect-secondary
       options have been updated to also work with InnoDB
       ReplicaSet.
       When running MySQL Shell, use the
       shell.connectToPrimary([connectionData, password]) to
       check whether the target instance belongs to an InnoDB
       cluster or InnoDB ReplicaSet. If so, MySQL Shell opens a
       new session to the primary, sets the global session to
       the established session and returns it. If no
       connectionData is provided, the current global session is
       used.

AdminAPI Bugs Fixed

     * During distributed recovery which is using MySQL Clone,
       the instance restarts after the data files are cloned,
       but if the instance has to apply a large back log of
       transactions to finish the recovery process, then the
       restart process could take longer than the default 1
       minute timeout. Now, when there is a large back log use
       the dba.restartWaitTimeout option to configure a longer
       timeout to ensure the apply process has time to process
       the transactions. (Bug #30866632)

     * The dba.deleteSandboxInstance() operation did not provide
       an error if you attempted to delete a sandbox which did
       not exist. Now, in such a situation the
       dba.deleteSandboxInstance() operation throws a
       runtimeError. (Bug #30863587)

     * The Cluster.forceQuorumUsingPartitionOf() operation was
       not stopping Group Replication on any reachable instances
       that were not part of the visible membership of the
       target instance, which could lead to undefined behavior
       if any of those instances were automatically rejoining
       the cluster. The fix stops Group Replication on any
       reachable instances that are not included in the new
       forced quorum membership. (Bug #30739252)

     * It was possible for AdminAPI to select an invalidated
       instance as the latest primary, despite it having a lower
       view_id. This was because the process of getting the
       primary of the InnoDB ReplicaSet was incorrectly
       reconnecting to an invalidated member if it was the last
       instance in the InnoDB ReplicaSet. (Bug #30735124)

     * When a cluster that was created with a MySQL Shell
       version lower than 8.0.19 was offline (for example after
       a server upgrade of the instances), if you then used
       MySQL Shell 8.0.19 to connect to the cluster,
       dba.upgradeMetadata() and
       dba.rebootClusterFromCompleteOutage() blocked each other.
       You could not run dba.upgradeMetadata() because it
       requires dba.rebootClusterFromCompleteOutage() to be run
       first to bring the cluster back online. And you could not
       run dba.rebootClusterFromCompleteOutage() because
       dba.upgradeMetadata() had not been run. To avoid this
       problem please upgrade to MySQL Shell 8.0.20, where the
       preconditions for dba.rebootClusterFromCompleteOutage()
       and dba.forceQuorumUsingPartitionOf() have been updated
       to ensure they are compatible with clusters created using
       earlier versions. In other words, they are available even
       if the metadata was created using an older MySQL Shell
       version. (Bug #30661129)

     * Using MySQL Clone as the distributed recovery method to
       add an instance to an InnoDB ReplicaSet resulted in a
       segmentation fault if the target instance did not support
       RESTART. Now, the ReplicaSet.addInstance() operation
       aborts in such a situation and reverts changes after the
       connection timeout limit is reached. This is because the
       add operation needs to connect to the target instance to
       finish the operation. In such a situation, if it is not
       possible to upgrade the instance to a version of MySQL
       which supports RESTART, you have to restart the server
       manually, and then issue ReplicaSet.addInstance() again
       to retry. The retry can then use incremental recovery,
       which does not trigger the clone and the subsequent
       restart. (Bug #30657911)

     * Cluster.addInstance() normally fails if there are errant
       GTIDs in the added instance, but if MySQL Clone is being
       used for distributed recovery, that check is bypassed
       because the cloning process fixes the problem. However,
       if all members are using IPv6, MySQL Clone cannot be
       used, so incremental recovery is used instead. In such a
       situation, the instance was being added to the cluster
       without errors, but the errant transaction persisted.
       Now, if all of the cluster’s online instances are using
       IPv6 addresses and the operation tries to use MySQL Clone
       for distributed recovery, an error is thrown. (Bug
       #30645697)

     * When an InnoDB cluster or InnoDB ReplicaSet is using the
       MySQL Clone plugin, AdminAPI ensures the
       performance_schema.clone_status table is cleared out when
       the clone process starts. However, in some rare and very
       specific scenarios a race condition could happen and the
       clone operation was considered to be running before
       actually clearing out the table. In this situation, the
       MySQL Shell clone monitoring could result in an
       unexpected halt.
       As part of this fix, a potential infinite loop in the
       clone monitoring phase that could happen very rarely when
       the cloning process was extremely fast has also been
       fixed. (Bug #30645665)

     * Group Replication system variable queries were being
       executed early, without considering whether the Group
       Replication plugin was installed yet. Now, the reboot
       operation has been fixed so that if system variable
       queries fail with ER_UNKNOWN_SYSTEM_VARIABLE then the
       Group Replication plugin is installed automatically. (Bug
       #30531848)

     * The Cluster.removeInstance(instance) operation was not
       correctly handling the following cases:

          + if the instance had report_host set to a different
            value from the instance_name in the metadata,
            specifying the instance using its IP failed.

          + if the instance was unreachable, it was not possible
            to remove it if the given address did not match the
            address in the metadata.

          + when an instance was OFFLINE but reachable (for
            example because Group Replication stopped but the
            server was still running),
            Cluster.removeInstance(instance) failed. Now, in
            such a situation, if you are sure it is safe to
            remove the instance, use the force=true option,
            which means that synchronization is no longer
            attempted as part of the remove operation.

          + if the instance was OFFLINE but reachable, removing
            the instance through an address that did not match
            what was in the metadata would make the operation
            appear to succeed but the instance was not actually
            removed from the metadata.
       (Bug #30501628, Bug #30625424)

     * After operations such as removing an instance or
       dissolving a cluster, the group_replication_recovery and
       group_replication_applier replication channels were not
       being removed. (Bug #29922719, Bug #30878446)

     * The default location of the MySQL option file, for
       example /etc/my.cnf, stopped being detected by the
       dba.configureInstance() operation on some platforms
       (Debian and so on). This was a regression. The fix
       ensures that the predefined paths to option files matches
       the defaults, such as /etc/my.cnf and /etc/mysql/my.cnf.
       (Bug #96490, Bug #30171324)

Functionality Added or Changed

     * A new method shell.openSession is provided in the shell
       global object to let you create and return a session
       object, rather than set it as the global session for
       MySQL Shell.

     * You can now request compression for MySQL Shell
       connections that use X Protocol, as well as those that
       use classic MySQL protocol. For X Protocol connections,
       the default is that compression is requested, and
       uncompressed connections are allowed if the negotiations
       for a compressed connection do not succeed. For classic
       MySQL protocol connections, the default is that
       compression is disabled. After the connection has been
       made, the MySQL Shell \status command shows whether or
       not compression is in use for a session.
       New compression controls in MySQL Shell let you specify
       in the connection parameters whether compression is
       required, preferred, or disabled, select compression
       algorithms for the connection, and specify a numeric
       compression level for the algorithms.

Bugs Fixed

     * When you create an extension object for MySQL Shell, the
       options key is no longer required when you specify a
       parameter of the data type “dictionary”. If you do define
       options for a dictionary, MySQL Shell validates the
       options specified by the end user and raises an error if
       an option is passed to the function that is not in this
       list. If you create a dictionary with no list of options,
       any options that the end user specifies for the
       dictionary are passed directly through to the function by
       MySQL Shell with no validation. (Bug #30986260)

     * A bug in MySQL Shell 8.0.19, affecting classic MySQL
       protocol connections only, meant that access was denied
       if a user had stored the connection’s password with MySQL
       Shell and afterwards changed it. The password store now
       removes invalid passwords and presents the user with a
       password prompt as expected. (Bug #30912984, Bug #98503)

     * When MySQL Shell’s \source command was used in
       interactive mode to execute code from a script file,
       multi-line SQL statements in the script file could cause
       MySQL Shell to enter a loop of repeatedly executing the
       script. The issue has now been fixed. (Bug #30906751, Bug
       #98625)

     * If a stored procedure was called in MySQL Shell but its
       result was not used, any subsequent SQL statement
       returned a result set error, and exiting MySQL Shell at
       that point resulted in an incorrect shutdown. MySQL Shell
       cleared the first result set retrieved by a stored
       procedure in order to run a subsequent SQL statement, but
       did not check for any additional result sets that had
       been retrieved, which were left behind and caused the
       error. This check is now carried out and the additional
       result sets are discarded before another statement is
       executed. (Bug #30825330)

     * Due to a regression in MySQL Shell 8.0.19, the upgrade
       checker utility checkForServerUpgrade() did not accept
       any runtime options if connection data was not provided
       as the first argument. The issue has been fixed and the
       utility’s argument checking has been enhanced. (Bug
       #30689606)

     * MySQL Shell, which now bundles Python 3.7.4, could not be
       built from source with Python 3.8. The incompatibilities
       have now been corrected so Python 3.8 may be used. (Bug
       #30640012)

     * MySQL Shell’s upgrade checker utility
       checkForServerUpgrade() did not flag removed system
       variables that were specified using hyphens rather than
       underscores. The utility also now continues with its
       sequence of checks if a permissions check cannot be
       performed at the required time. (Bug #30615030, Bug
       #97855)

     * MySQL Shell’s \status command showed that a connection
       was compressed if the connection had been created while
       starting MySQL Shell, but not if it was created after
       starting MySQL Shell. Compression is now shown in both
       cases. (Bug #29006903)


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

MySQL Connector/J 8.0.21 has been released

Posted on by

Dear MySQL users,

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

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

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

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

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

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

Enjoy!

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

* Functionality Added or Changed

* Bugs Fixed Functionality Added or Changed

Functionality Added or Changed

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

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

Bugs Fixed

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

On Behalf of MySQL Release Engineering Team,
Surabhi Bhat




MySQL Connector/Node.js 8.0.21 has been released

Posted on by

Dear MySQL users,

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

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.

Changes in MySQL Connector/Node.js 8.0.21 (2020-07-13, General Availability)

Functionality Added or Changed

* Creating a collection now supports options to enable validation of a JSON schema that documents must adhere to before they are permitted to be inserted or updated. The new ModifyCollection method allows updating the schema of an existing collection. In the createCollection method, the option to re-use an existing collection was renamed from ReuseExistingObject to reuseExisting. Schema validation is performed by the server, which returns an error message if a document in a collection does not match the schema definition or if the server does not support validation. If a given collection already exists in the database, the createCollection fails unless the reuseExisting property is enabled in an additional options object such as the following example:

const mysqlx = require(‘@mysql/xdevapi’);

mysqlx.getSession(‘mysqlx://localhost:33060’)
.then(sesion => {
return session.getSchema(‘mySchema’).createCollection(‘myColle
ction’, { reuseExisting: true })
});

You can also use the options object to, for example, create a server-side document validation schema. For that, you can include a schema property matching a valid JSON schema definition within an outer validation object. You should also include the level property where STRICT enables it and OFF disables it. For example:

const mysqlx = require(‘@mysql/xdevapi’);
const validation = { schema: { type: ‘object’, properties: { name: { t
ype: ‘string’ } } }, level: mysqlx.Schema.ValidationLevel.STRICT };

mysqlx.getSession(‘mysqlx://localhost:33060’)
.then(sesion => {
return session.getSchema(‘mySchema’).createCollection(‘myColle
ction’, { validation })
});

The same level property logic applies to modifyCollection. Here’s an example to enable a JSON schema on an existing collection (or to update it if it already exists) using the STRICT validation level:

const mysqlx = require(‘@mysql/xdevapi’);
const validation = { schema: { type: ‘object’, properties: { name: { t
ype: ‘string’ } } }, level: mysqlx.Schema.ValidationLevel.STRICT };

mysqlx.getSession(‘mysqlx://localhost:33060’)
.then(sesion => {
return session.getSchema(‘mySchema’).modifyCollection(‘myColle
ction’, { validation })
});

Bugs Fixed

* Row values for columns of type BIGINT were not correctly decoded by Connector/Node.js. Upgrading the google-protobuf library (to 3.11.4) fixed this problem. (Bug #27570685)

On Behalf of MySQL/ORACLE RE Team
Gipson Pulla

MySQL Connector/C++ 8.0.21 has been released

Posted on by

Dear MySQL users,

MySQL Connector/C++ 8.0.21 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/

See also “X DevAPI Reference” at

https://dev.mysql.com/doc/dev/connector-cpp/devapi_ref.html

and “X DevAPI for C Reference” at

https://dev.mysql.com/doc/dev/connector-cpp/xapi_ref.html

For generic information on using Connector/C++ 8.0, see

https://dev.mysql.com/doc/dev/connector-cpp/

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/C++ 8.0.21, see the “General Availability (GA)
Releases” tab at

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

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

Configuration Notes


     * The CMake configuration files were revised to work better
       when Connector/C++ is used as a subproject of application
       projects. Thanks to Lou Shuai for the contribution.
       This revision does not change the fact that the intended
       (and supported) usage scenario is to build the connector
       in a separate project, install it somewhere and then use
       it in application projects from that installed location
       (for example, by defining the imported library target in
       CMake). (Bug #31095993, Bug #99093)

JSON Notes


     * The rapidjson library included with Connector/C++ has
       been upgraded to the GitHub snapshot of 16 January 2020.

Security Notes


     * For platforms on which OpenSSL libraries are bundled, the
       linked OpenSSL library for Connector/C++ has been updated
       to version 1.1.1g. Issues fixed in the new OpenSSL
       version are described at
https://www.openssl.org/news/cl111.txt and
https://www.openssl.org/news/vulnerabilities.html. (Bug
       #31296689)

X DevAPI Notes


     * For X DevAPI or X DevAPI for C applications, methods and
       functions that create or modify collections now accept
       options to enable validation of a JSON schema that
       documents must adhere to before they are permitted to be
       inserted or updated. Schema validation is performed by
       the server, which returns an error message if a document
       in a collection does not match the schema definition or
       if the server does not support validation.
       These new classes are implemented to support validation
       options:

          + CollectionOptions: The base class that has all
            options. Contains an Option enumeration with
            constants REUSE and VALIDATION.

          + CollectionValidation: Handles only subkey
            validation. Contains a Level enumeration with
            constants STRICT and OFF, and an Option enumeration
            with constants SCHEMA and LEVEL.
       X DevAPI now has these signatures for createCollection()
       (and modifyCollection()):
       // Accepts the full document
       createCollection(“name”, “JSON_Document”);

       // DbDoc usage is also permitted
       createCollection(“name”, DbDoc(“validation”, DbDoc(“level”,”off”,…)));

       // List of pairs with Option enum constant and value
       createCollection(CollectionOptions::REUSE, true,
                 CollectionOptions::VALIDATION, CollectionValidation(…));

       // Old REUSE way is also acceptable
       createCollection(“name”, true);

       createCollection(“name”, CollectionValidation(…));

       // createCollection also allows a list of pairs of
       // CollectionValidation Option enum constant and value
       createCollection(“name”, CollectionOptions::VALIDATION,
                         CollectionValidation::OFF,
                         CollectionValidation::SCHEMA,
                         “Object”);

       X DevAPI for C examples:
       These are the possible options for
       mysqlx_collection_options_set():
       OPT_COLLECTION_VALIDATION_LEVEL(VALIDATION_OFF)
       OPT_COLLECTION_VALIDATION_SCHEMA(“Object”)
       OPT_COLLECTION_REUSE(true)

       Perform option operations like this:
       mysqlx_collection_options_t *options = mysqlx_collection_options_new() //creates collection options object
       mysqlx_free(options) //frees collection options
       mysqlx_collection_options_set(options,…);

       Creation and modification functions have these signatures:
       mysqlx_collection_create_with_options(mysqlx_schema_t *schema, mysqlx_collection_options_t *options);

       mysqlx_collection_create_with_json_options(mysqlx_schema_t *schema, const char* json_options);

       mysqlx_collection_modify_with_options(mysqlx_schema_t *schema, mysqlx_collection_options_t *options);

       mysqlx_collection_modify_with_json_options(mysqlx_schema_t *schema, const char* json_options);

       For modifications, the REUSE option is not supported and
       an error occurs if it is used.

Functionality Added or Changed


     * The MySQL_Connection_Options enumeration is no longer
       sensitive to the order in which the underlying options
       are declared in the C API source. (Bug #30799197)

     * Connector/C++ now implements blocking of failed
       connection-pool endpoints to prevent them from being
       reused until a timeout period has elapsed. This should
       reduce average wait time for applications to obtain a
       connection from the pool in the event that endpoints
       become temporarily unavailable.

Bugs Fixed


     * For applications that use the legacy JDBC API (that is,
       not X DevAPI or X DevAPI for C) on a system that does not
       have OpenSSL libraries installed, the libraries that are
       bundled with Connector/C++ could not be found when
       resolving run-time dependencies of the application. (Bug
       #31007317)

     * For a reply with multiple result sets (such as the result
       from a stored procedure that executed multiple queries),
       an error in reply processing logic could incorrectly
       deregister the reply object after reading the first
       result set while more result sets from the server were
       pending, resulting in an application error. (Bug
       #30989042)

On Behalf of Oracle/MySQL Release Engineering Team,

Hery Ramilison 

MySQL Connector/NET 8.0.21 has been released

Posted on by

Dear MySQL users,

MySQL Connector/NET 8.0.21 is the latest General Availability release of
the MySQL Connector/NET 8.0 series. This version supports .NET Core 3.1
and the 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.21, 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.21 (2020-07-13, General
Availability)

Functionality Added or Changed

     * The following ciphers and algorithms are deprecated for
       SSH connections made using Connector/NET:
       Encryptions

          + 3des-cbc
       Key Exchange Algorithms

          + diffie-hellman-group14-sha1

          + diffie-hellman-group-exchange-sha1
       Message Authentication Codes

          + hmac-ripemd160

          + hmac-sha1

          + hmac-sha1-96
       (Bug #31030347)

Bugs Fixed

     * Connector/NET returned an error when the name of a
       database or stored procedure contained one or more period
       characters. Now, names with this format can be used when the name
       is enclosed properly between grave accent (`) symbols; for
       example, `db_1.2.3.45678`. (Bug #31237338, Bug #99371)

     * An error was generated when the database name within a
       connection string that was passed to MySQL 5.6 or MySQL 5.7 did
       not match the casing used to search a related stored procedure.
       (Bug #31173265)

     * In Connector/NET 8.0.19, calling new
       MySqlConnection(null) returned NullReferenceException, rather
       than returning an object with a ConnectionString property equal
       to String.Empty as the previous versions of Connector/NET did.
       This fix restores the earlier behavior. (Bug #30791289,
       Bug #98322)

     * An expected empty result set generated by executing
       MySQLDataReader for a stored procedure instead returned a data
       table containing the @_cnet_param_value column. This fix
       eliminates an internal error that affected the result set and now
       GetSchemaTable() returns a null value as expected.
       (Bug #30444429, Bug #97300)

     * The BLOB type was inferred internally when a value or
       object of type MySqlGeometry was used in different situations,
       which caused to server to return either zero matching rows or an
       exception. (Bug #30169716, Bug #96499, Bug #30169715, Bug #96498)

     * Attempts to execute a function or stored procedure
       returned a null exception unexpectedly when the caller was not
       the creator of the routine. This fix introduces a mechanism to
       manage null values for these cases, permits the granting of
       privilege to SHOW_ROUTINE, and revises SqlNullValueException to
       identify when a user account lacks adequate permission to access
       a routine. (Bug #30029732, Bug #96143)

     * Columns of type BIGINT in a table that was loaded using
       MySqlDataReader did not include the UNSIGNED flag, even though
       UNSIGNED was specified in the CREATE TABLE statement. An
       exception was generated if the value of such a column exceeded
       2147483647. (Bug #29802379, Bug #95382)

     * The microseconds value in the return results was set to
       zero consistently when SqlCommand.Prepare() was called for a
       SELECT statement with a TIME(n) column. This fix revises the way
       the value is produced to ensure accurate results. (Bug #28393733,
       Bug #91770)

     * The isolation level set for a transaction did not revert
       to using the session value after the transaction finished.
       (Bug #26035791, Bug #86263)

     * A valid call made to the
       MySqlSimpleRoleProvider.AddUsersToRoles method failed to execute
       because it violated the foreign key constraint. This fix removes
       an error from the code that gets the role ID. Thanks to Stein
       Setvik for the patch. (Bug #25046352, Bug #83657)

     * The absence of a target schema in the generated WHERE
       statement produced during an Entity Framework migration caused an
       error when the identical table was present in multiple databases.
       This fix adds the table_schema column to the generated SQL query.
       (Bug #23291095, Bug #72424)

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

MySQL Connector/ODBC 8.0.21 has been released

Posted on by

Dear MySQL users,

MySQL Connector/ODBC 8.0.21 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 out 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.21 (2020-07-13, General Availability)


     * Security Notes

     * Bugs Fixed

Security Notes


     * For platforms on which OpenSSL libraries are bundled, the
       linked OpenSSL library for Connector/ODBC has been
       updated to version 1.1.1g. Issues fixed in the new
       OpenSSL version are described at
https://www.openssl.org/news/cl111.txt and
https://www.openssl.org/news/vulnerabilities.html.
        (Bug#31296688)

Bugs Fixed


     * The MSI installer now checks for the Visual 2019 C++
       runtime, and aborts if this required runtime is not
       installed.
        This is also the first version that requires Visual 2019
        C++ runtime, when before the 2017 version was also
        supported. (Bug #31102234)

     * Only a single value was being inserted instead of the
        array, with SQLParamOptions. (Bug #30591722)

     * The SUM aggregate function did not function with ADO.
       (Bug #30277891, Bug #96642)

     * Added a workaround to account for a limitation in the
       iODBC SQLGetPrivateProfileString() implementation as
       previously DSN options could be lost. iODBC is most
       commonly used on macOS. (Bug #27851681)


On Behalf of Oracle/MySQL Engineering Team
Prashant Tekriwal

MySQL Connector/Python 8.0.21 has been released

Posted on by

Dear MySQL users,

MySQL Connector/Python 8.0.21 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.21, see the “General Availability
(GA) Releases” tab at

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

Enjoy!

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

Functionality Added or Changed

* Implemented context managers to define the runtime
context to establish when executing a with statement. It
was added to the Connection and Cursor objects in the
classic protocol, and to Session in the X DevAPI. Thanks
to WEN-FENG SHIH for the patch. (Bug #19586444, Bug
#71663, Bug #28779784, Bug #89113)

* Added compression support to X Protocol connections.
Supported compression algorithms are zlib/deflate and
lz4. Specifically, the supported algorithms (in order of
preference) are lz4_message and deflate_stream. The
compression threshold is set at 1000 bytes.
A new compress X DevAPI connection option accepts either
required, disabled, or preferred (default).

+ preferred: If Connector/Python and the server cannot
reach consensus on algorithm or styles, then no
compression is used; and this is logged.

+ required: Like preferred, except the connection is
terminated with an error if the connector and server
are unable to reach agreement.

+ disabled: Compression is not used.

Bugs Fixed

* The connect_timeout option applied to all blocking socket
operations but now properly only applies to the timeout
when establishing the connection. (Bug #30996790)

* In X DevAPI implementation, an error was raised when
using the fractional part in DATETIME types. The error:
“ValueError: Datetime mapping scenario unhandled” (Bug
#30950184)

* Because MySQL stores TEXT types as BLOB and JSON as
LONGBLOB, the TEXT and JSON types are now converted to
str and the rest of the BLOB types as bytes. Previously,
as an example, a column of type TEXT that only contained
digits was read as type=integer by Connector/Python. (Bug
#29808262, Bug #95437)

* Connector/Python assumed that MySQL libraries were under
lib/ when compiling the C extension, but now uses the
mysql_config flags which adds the correct include and
libraries paths. Thanks to Daniël van Eeden for the
patch. (Bug #29181907, Bug #93846)

On Behalf of Oracle/MySQL Engineering Team,
Balasubramanian Kandasamy

MySQL Connector/NET provider for Entity Framework Core 3.1

Posted on by

Hello MySQL Connector/NET community,

Keeping an ongoing pace to support the latest technologies, we are pleased to announce the latest updates regarding MySQL Connector/NET and Entity Framework Core.

As you may know, Entity Framework Core 3.1 is the latest and long-term support (LTS) release, meaning that it will be supported for at least 3 years. It has a primary goal to polish the EF Core 3.0 version and reintroduces support for .NET Standard 2.0, so it will run on .NET Frameworks versions that support the standard. In our continuous effort to keep up on the latest technologies, we would like to share with you that our latest GA release, Connector/NET 8.0.20, comes with full support for EF Core 3.1.

Let’s have a short demonstration on how to use Connector/NET and EF Core. We are going to use the Code First process to create the database in our server and build up our Entity Model in a Console Application.

Prerequisites:
– Visual Studio 2019
– .NET Core 3.1 SDK
– MySQL Server
– Connector/NET 8.0.20 (this could be obtained on our site or by using NuGet)

We are going to start by creating a console application and in this case, we are going to do it by using .NET Core CLI:

dotnet new console -o EFCoreSample

If we look into the .csproj file of our application, we can see that the TargetFramework have been set to netcoreapp3.1. Then we need to add our EF Core Connector/NET NuGet package to the project:

dotnet add package MySql.Data.EntityFrameworkCore –-version
8.0.20

So now that we have our console application and the EF Core Connector/NET package installed, we can start writing our context and entity classes. Create a class called Model.cs in the project directory with the following code:

using System.Collections.Generic;
using Microsoft.EntityFrameworkCore;
using MySql.Data.EntityFrameworkCore.DataAnnotations;

namespace EFCoreSample
{
  public class LibraryContext : DbContext
  {
    public DbSet<Book> Book { get; set; }
    public DbSet<Publisher> Publisher { get; set; }

    protected override void OnConfiguring(DbContextOptionsBuilder options)
        => options.UseMySQL("server=localhost;database=efcoresample;user=efcore;password=");

    protected override void OnModelCreating(ModelBuilder modelBuilder)
    {
      base.OnModelCreating(modelBuilder);

      modelBuilder.Entity<Publisher>(entity =>
      {
        entity.HasKey(e => e.ID);
        entity.Property(e => e.Name).IsRequired();
      });

      modelBuilder.Entity<Book>(entity =>
      {
        entity.HasKey(e => e.ISBN);
        entity.Property(e => e.Title).IsRequired();
        entity.HasOne(d => d.Publisher)
          .WithMany(p => p.Books);
      });
    }
  }

  [MySqlCollation("latin1_spanish_ci")]
  public class Book
  {
    [MySqlCharset("latin1")]
    public string ISBN { get; set; }

    public string Title { get; set; }
    public string Author { get; set; }
    public string Language { get; set; }
    public int Pages { get; set; }
    public virtual Publisher Publisher { get; set; }
  }

  public class Publisher
  {
    public int ID { get; set; }
    public string Name { get; set; }
    public virtual ICollection<Book> Books { get; set; }
  }
}

Now that we have our context and entity classes set up, we can start using our model the way we want to, in this example we are going to insert a couple of records and then print them in screen. On the main class of our project (Program.cs) we are going to add two methods, one to insert data and another to print it:

using System;
using System.Text;
using Microsoft.EntityFrameworkCore;

namespace EFCoreSample
{
  class Program
  {
    static void Main(string[] args)
    {
      InsertData();
      PrintData();
      Console.ReadKey();
    }

    private static void InsertData()
    {
      using (var context = new LibraryContext())
      {
        // Creates the database if not exists
        context.Database.EnsureCreated();

        // Adds a publisher
        var publisher = new Publisher
        {
          Name = "Mariner Books"
        };
        context.Publisher.Add(publisher);

        // Adds some books
        context.Book.Add(new Book
        {
          ISBN = "978-0544003415",
          Title = "The Lord of the Rings",
          Author = "J.R.R. Tolkien",
          Language = "English",
          Pages = 1216,
          Publisher = publisher
        });
        context.Book.Add(new Book
        {
          ISBN = "978-0547247762",
          Title = "The Sealed Letter",
          Author = "Emma Donoghue",
          Language = "English",
          Pages = 416,
          Publisher = publisher
        });

        // Saves changes
        context.SaveChanges();
      }
    }

    private static void PrintData()
    {
      // Gets and prints all books in database
      using (var context = new LibraryContext())
      {
        var books = context.Book.Include(p => p.Publisher);
        foreach (var book in books)
        {
          var data = new StringBuilder();
          data.AppendLine($"ISBN: {book.ISBN}");
          data.AppendLine($"Title: {book.Title}");
          data.AppendLine($"Publisher: {book.Publisher.Name}");
          Console.WriteLine(data.ToString());
        }
      }
    }
  }
}

And that’s it! A quick look on how to build an EF Core 3.1 application using MySQL Connector/NET as the provider. This is just a small demonstration of what ypu can do with EF Core. There are many features in EF Core to use and we are pleased to tell you that Connector/NET has full support for them.

We hope you find this information useful to start using MySQL Connector/NET with the most recent technologies. Your feedback is always welcome and all your comments inspire us to keep improving so that we offer you a product with top quality.

Finally, here are some links that could be useful for you:

We hope to hear from you!

MySQL Connector/J 5.1.49 GA has been released

Posted on by

Dear MySQL Users,

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

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

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

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

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

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

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

     * Functionality Added or Changed

     * Bugs Fixed

Functionality Added or Changed

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

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

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

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

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

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

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

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

Bugs Fixed


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

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

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

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

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

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


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