Deprecating End-of-life runtime engines on Connector/Node.js

Starting with the 8.0.23 release, Connector/Node.js will be deprecating support for End-of-life Node.js engine versions. Support for these versions will eventually be removed on subsequent releases which will focus on compatibility with the available LTS versions at the date of each release.

Continue reading

MySQL Connector/Node.js 8.0.23 has been released


Dear MySQL users,

MySQL Connector/Node.js is a new Node.js driver for use with the X
DevAPI. This release, v8.0.23, 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.23 (2021-01-18, General Availability)

* Functionality Added or Changed
* Bugs Fixed

Functionality Added or Changed

* Added custom debug functionality using the NODE_DEBUG
environment variable to log and inspect low-level details
for the application. Connector/Node.js now supports this
feature and uses it, in particular, for logging
information about the protocol messages (inbound and
outbound) that are exchanged with the MySQL server.
Messages sent by the client are available under the
protocol:outbound scope, whereas messages sent by the
server are available under the protocol:inbound scope.
For example, the following writes a textual protobuf
representation of every Mysqlx.Crud.Find and
Mysqlx.Resultset.Row message to stderr: shell> NODE_DEBUG=’protocol:outbound:Mysqlx.Crud.Find,protocol:inbound :Mysqlx.Resultset.Row’ node app.js

Node 10 and later supports wildcard pattern matching,
such as NODE_DEBUG=’protocol:inbound:*’ to filter out
inbound messages and NODE_DEBUG=’*’ to show all logs.
(Bug #31729043)

* Added a deprecation warning to the Connector/Node.js
installation process that future Connector/Node.js
versions do not guarantee compatibility with End-of-life
Node.js versions. If you are planning to upgrade, make
sure you are using Node.js 12.0.0 or higher.

Bugs Fixed

* Stored values in a DOUBLE column were truncated when
encoded and sent to the MySQL server. For example, a
value such as 1.000001 would become 1. They are now
encoded properly as double-precision floating numbers to
support the full range of 64-bit floating point precision
in MySQL columns with the DOUBLE data type (having in
mind possible rounding an approximations performed by the
database engine). (Bug #31734504)

* Improved consistency for method argument error handling
when an argument is not set or uses JavaScript’s
“undefined”. (Bug #31709879)

* Refactored code to disable all debugging utilities when
debug mode is off. (Bug #31584269)

On Behalf of MySQL Release Engineering Team,
Surabhi Bhat

Rethinking Result Sets in Connector/Node.js

It used to be the case where, in order to actually process data retrieved from the database using Connector/Node.js, you would have to resort to an API that required the use of both JavaScript callbacks and Promises. This was meant to provide more flexibility and control to the application developer and at the same time decrease the chance of buffering data unnecessarily. However this wasn’t useful for 99% of the use-cases and made simple tasks a little bit cumbersome. Also, the fact that it required using two different asynchronous constructs made it a little bit harder to grasp.

To make matters worse, in order to consume operational metadata about the columns in the result set, you would have to provide an additional callback, making the whole thing spiral a bit out of control, particularly when there were multiple result sets involved. In that case, you needed to create a shared context between the two functions in order to map data and metadata for each column in each result set.

Continue reading