MySQL Connector/C++ Release Notes
The renaming of the utf8
character set to
utf8mb3
in MySQL 8.0.30—together with
new utf8mb4
collations—generated errors
related to collation names. To support the character-set name
change and the new collations, several API changes now are
implemented.
For applications using X DevAPI or X DevAPI for C (breaking changes):
The CharacterSet::utf8
enumeration constant was
renamed to CharacterSet::utf8mb3
, but the
constant value (21) did not change. Compiling an existing
application against the new connector produces errors if
code refers to the CharacterSet::utf8
enumeration constant.
Code that uses CharacterSet::utf8mb3
without
also using the new utf8mb4
collations
can be expected to work with the old connector library,
but only after it has been compiled using the new
connector header files.
The name returned by the characterSetName()
function for the value of
CharacterSet::utf8/utfmb3
constant (21) changed
from "utf8" to "utf8mb3".
Collation names returned by the
CollationInfo::getName()
method for
CollationInfo
members in
Collation<21>
have changed. For example,
Collation<21>::general_ci.getName()
now
returns “utf8mb3_general_ci” instead of
“utf8_general_ci”.
Although not a breaking change, all of the new
CollationInfo
members, such as
utf8mb4_bg_0900_ai_ci
, have been added
(for example,
Collation<CharacterSet::utf8mb4>::bg_0900_ai_ci
).
For applications using the legacy JDBC API (breaking changes):
The character-set name returned by the
MySQL_PreparedResultSetMetaData::getColumnCharset()
and MySQL_ResultSetMetaData::getColumnCharset()
methods for the character set
utf8/utf8mb3
has changed from "utf8" to
"utf8mb3".
Collation names returned by the
MySQL_PreparedResultSetMetaData::getColumnCollation()
and
MySQL_ResultSetMetaData::getColumnCollation()
methods for utf8/utf8mb3
have changed.
For example, the previous collation "utf8_general_ci" is now
replaced with "utf8mb3_general_ci".
Existing applications that contain logic for checking the
utf8
character-set name, or one of its
collations, can expect errors when used with the new connector.
If an application must be compiled with a pre-8.0.30 connector,
then all of the character-set and collation comparisons should
be guarded with the
MYSQL_CONCPP_VERSION_NUMBER
macro. For usage
examples, see
Connector/C++ Version Macros.
Each related ABI remains backward compatible, which means that
an application built against old connector sources can link
correctly to the new connector library. However, the new library
now reports different character-set and collation names for
utf8
and this difference might break the
code's logic.
(Bug #34149700)
Generic Linux packages now are built using the GNU C Library
version 2.27 and the new C++ ABI
(_GLIBCXX_USE_CXX11_ABI=1
). For additional
information about this change, see
Generic Linux Notes.
(Bug #33983351)
Connector/C++ now provides the
MYSQL_CONCPP_VERSION_NUMBER
macro in public
header files to indicate the current version of the connector.
The format of MYSQL_CONCPP_VERSION_NUMBER
is
XYYZZZZ
, in which:
X
is the major version number (8)
YY
is the minor version number
(00)
ZZZZ
is the micro version number
(0030)
With this macro, code that depends on one or more features that were introduced in a specific version (such as 8.0.32) can perform a conditional test in the compilation of portion of a source file. For example:
#if MYSQL_CONCPP_VERSION_NUMBER > 8000032 // use some 8.0.32+ feature #endif
This type of conditional-compilation directive also works when
the MYSQL_CONCPP_VERSION_NUMBER
macro is not
defined (with pre-8.0.30 header files), in which case, it is
treated as 0. However, using the macro to check against versions
earlier than 8.0.30 is unreliable and should be avoided.
For additional usage examples, see Connector/C++ Version Macros. (WL #15081)
It is now possible to compile Connector/C++ using OpenSSL 3.0. (WL #14819)
The Protobuf sources bundled with Connector/C++ were updated to Protobuf 3.19.4. To reduce compilation time, this update includes only the parts needed for Connector/C++. (WL #15084)
A valid query emitted an error when one or more fields were of
spatial data type GEOMETRY
and it
was executed using a prepared statement.
(Bug #19192707)