2009.09.23

MySQL

MySQL Connector/J 5.1.10がリリースされました

オリジナル版:http://lists.mysql.com/java/9276

バージョン5.1版でのメンテナンスリリースであるMySQL Connector/J 5.1.10が リリースされました。Connector/Jは、MySQL用のタイプ4のpure-Java JDBCドライバです。

バージョン5.1.10は、MySQL-4.1、MySQL-5.0、MySQL-5.1 RC、MySQL-5.4パフォーマンスリリースを含んだいくつかのMySQLのバージョンでの使用にふさわしいリリースです。

現在、Connector/Jダウンロードページ、およびミラーサイトからソースとバイナリ形式が入手可能です。

http://dev.mysql.com/downloads/connector/j/5.1.html

(すべてのミラーサイトが現在において最新であるとは限らないかもしれないことに注意してください。あるミラーサイトでこのバージョンを見つけることができない場合は、再度確認を行うか、あるいは別のダウンロードサイトを選択してください。)

いつものことですが、アプリケーションに影響を及ぼす動作変更を把握するには、アップグレードの前に、マニュアルの変更ログ

http://dev.mysql.com/doc/refman/5.1/en/cj-news.html)

と"Upgrading"の節

http://dev.mysql.com/doc/refman/5.1/en/cj-upgrading.html

をチェックするようお勧めします。

バグレポート、バグ修正、パッチ等の情報をお待ちしておりますので、以下のページをご利用ください。

http://forge.mysql.com/wiki/Contributing

 

以下は、Connector/J 5.10.の変更情報です。

MySQL Connector/J 5.1.10 fixes a regression introduced with the  
recently released 5.1.9:

- Fix for BUG#47494 - Non standard port numbers in the URL are not
honored.

(sorry for the regression, astute observers of the commit list should
notice that we're now running tests on non-standard ports in our
Hudson environment to avoid this happening again!)

And contains the following changes from 5.1.9 (just in case you missed
it):

- Fix for a variant of Bug#41484 - ResultSet.find*(String) failed
when using cached result set metadata.

- Added a new option, "queryTimeoutKillsConnection", when set to
"true" will cause timeouts set by Statement.setQueryTimeout() to
forcibly kill the connection, not just the query.

- Fixed Bug#46788 - Batched prepared statements with ON DUPLICATE
KEY UPDATE are rewritten incorrectly when when there are parameters as
part of the UPDATE clause. Statements of this form can not be
rewritten as multi-value INSERTs so they are rewritten into multi-
statements instead.

As well as the following general bug fixes and improvements:

- The driver has been OSGi-ified. The bundle symbolic name is
"com.mysql.jdbc", see META-INF/MANIFEST.MF to see what interfaces we
export.

- Fixed BUG#45040, adding missing tags from SVN import to BZR
branch for 5.1.

- Fixed Bug#27431 - ResultSet.deleteRow() advances the cursor. The
driver now places the cursor on the prior row in the result set, or
before the start of the result set if the result set is empty after
the deletion.

- Fixed Bug#43759 - ResultSet.deleteRow() generates corrupt DELETE
statement for primary keys with binary data.

- Fixed Bug#46925 - Suspendable XA connections were not pinned to
the XID for the global transaction, leading to failure when attempting
to suspend/resume/commit from different logical XA connections.

- Fixed Bug#44508 - DatabaseMetadata.getSuperTypes() returns result
set with incorrect column names.

- Fixed BUG#32216, "PORT" property filled in by Driver.parseURL()
not always present. The driver will now always fill in the
"PORT" (using 3306 if not specified) property, and the "HOST"
property (using "localhost" if not specified) when parseURL() is
called. The driver also parses a list of hosts into HOST.n and PORT.n
properties as well as adding a property "NUM_HOSTS" for the number of
hosts it has found. If a list of hosts is passed to the driver, "HOST"
and "PORT" will be set to the values given by "HOST.1" and "PORT.1"
respectively. This change has centralized and cleaned up a large swath
of code used to generate lists of hosts, both for load-balanced and
fault tolerant connections and their tests.

- Fixed the ResultSet side of BUG#23584 - Calendar discarded when
retrieving dates from server-side prepared statements. The other cases
of this bug were fixed when "useLegacyDatetimeCode=false" became the
default.

- Fixed BUG#46637 - When the driver encounters an error condition
that causes it to create a CommunicationsException, it tries to build
a friendly error message that helps diagnose what is wrong. However,
if there has been no network packets received from the server, the
error message contains bogus information like:

"The last packet successfully received from the server was
1,249,932,468,916 milliseconds ago.
The last packet sent successfully to the server was 0
milliseconds ago."

Now the error message states that it has never received any
packets from the server in this scenario.

- Fixed Bug#44324 - Data truncation exceptions did not return the
vendor error code from the server. Note that the vendor error code is
not hard-coded to 1265 as in the bug report, because the server
returns different error codes for different types of truncations, and
we did not want to mask those.