 | | | Subject: MySQL Connector/J 5.1.3 RC is available! | Subject: MySQL Connector/J 5.1.3 RC is available! 2007-09-10 - By Mark Matthews
Back
-- --BEGIN PGP SIGNED MESSAGE-- --
Hash: SHA1
Hi,
MySQL Connector/J 5.1.3 RC, a new release candidate of the Type-IV pure-Java
JDBC driver for MySQL has been released.
Version 5.1.3 is suitable for use with any MySQL version including MySQL-4 (See http://SQL-4.ora-code.com).1,
MySQL-5 (See http://SQL-5.ora-code.com).0, MySQL-5 (See http://SQL-5.ora-code.com).1 beta or the MySQL-6 (See http://SQL-6.ora-code.com).0 Falcon alpha release.
It is now 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 (note that not all mirror sites may be up to date at this
point of time - if you can't find this version on some mirror, please try again
later or choose another download site.)
As always, we recommend that you check the change log
http://dev.mysql.com/doc/refman/5.0/en/cj-news.html
and "Upgrading" sections
http://dev.mysql.com/doc/refman/5.0/en/cj-upgrading.html
in the manual before upgrading as well as the "CHANGES" file in the download
archive to be aware of changes in behavior that might affect your application.
We welcome and appreciate your feedback, bug reports, bug fixes, patches etc.:
http://forge.mysql.com/wiki/Contributing
This is the release candidate of our implementation of the new JDBC-4 (See http://DBC-4.ora-code.com).0 API,
along with some new performance features.
This release candidate, as any other pre-production release, should not be
installed on production level systems or systems with critical data. It is good
practice to back up your data before installing any new version of software.
Although MySQL has worked very hard to ensure a high level of quality, protect
your data by making a backup as you would for any other software pre-production
release.
MySQL Connector/J 5.1.3 includes the following new feature compared to 5.1.2:
* Setting "useBlobToStoreUTF8OutsideBMP" to "true" tells the driver to treat
[MEDIUM/LONG]BLOB columns as [LONG]VARCHAR columns holding text encoded in UTF-8 (See http://UTF-8.ora-code.com)
that has characters outside the BMP (4-byte encodings), which MySQL server can
't handle natively.
Set "utf8OutsideBmpExcludedColumnNamePattern" to a regex so that column names
matching the given regex will still be treated as BLOBs The regex must follow
the patterns used for the java.util.regex package. The default is to exclude
no columns, and include all columns.
Set "utf8OutsideBmpIncludedColumnNamePattern" to specify exclusion rules to
utf8OutsideBmpExcludedColumnNamePattern". The regex must follow the patterns
used for the java.util.regex package.
* New methods on com.mysql.jdbc.Statement: setLocalInfileInputStream() and
getLocalInfileInputStream():
* setLocalInfileInputStream() sets an InputStream instance that will be
used to send data to the MySQL server for a "LOAD DATA LOCAL INFILE"
statement rather than a FileInputStream or URLInputStream that represents the
path given as an argument to the statement.
This stream will be read to completion upon execution of a "LOAD DATA
LOCAL INFILE" statement, and will automatically be closed by the driver, so it
needs to be reset before each call to execute*() that would cause the MySQL
server to request data to fulfill the request for "LOAD DATA LOCAL INFILE".
If this value is set to NULL, the driver will revert to using a
FileInputStream or URLInputStream as required.
* getLocalInfileInputStream() returns the InputStream instance that will be
used to send data in response to a "LOAD DATA LOCAL INFILE" statement.
This method returns NULL if no such stream has been set via
setLocalInfileInputStream().
* The driver now connects with an initial character set of "utf-8 (See http://utf-8.ora-code.com)" solely for
the purposes of authentication to allow usernames and database names in any
character set to be used in the JDBC URL.
* Errors encountered during Statement/PreparedStatement/CallableStatement
.executeBatch() when "rewriteBatchStatements" has been set to "true" now return
BatchUpdateExceptions according to the setting of "continueBatchOnError".
If "continueBatchOnError" is set to "true", the update counts for the "chunk"
that were sent as one unit will all be set to EXECUTE_FAILED, but the driver
will attempt to process the remainder of the batch. You can determine which
"chunk" failed by looking at the update counts returned in the
BatchUpdateException.
If "continueBatchOnError" is set to "false", the update counts returned will
contain all updates up-to and including the failed "chunk", with all counts for
the failed "chunk" set to EXECUTE_FAILED.
Since MySQL doesn't return multiple error codes for multiple-statements, or for
multi-value INSERT/REPLACE, it is the application's responsibility to handle
determining which item(s) in the "chunk" actually failed.
* Statement.setQueryTimeout()s now affect the entire batch for batched
statements, rather than the individual statements that make up the batch.
The following features are new, compared to the 5.0 series of Connector/J:
* JDBC-4 (See http://DBC-4.ora-code.com).0 ease-of-development features including auto-registration with the
DriverManager via the service provider mechanism, standardized Connection
validity checks and categorized SQLExceptions based on recoverability/retry
-ability and class of the underlying error.
* JDBC-4 (See http://DBC-4.ora-code.com).0 standardized unwrapping to interfaces that include vendor
extensions.
* Support for JDBC-4 (See http://DBC-4.ora-code.com).0 XML processing via JAXP interfaces to DOM, SAX and
StAX.
* JDBC-4 (See http://DBC-4.ora-code.com).0 support for setting per-connection client information (which can
be viewed in the comments section of a query via "SHOW PROCESSLIST" on a MySQL
server, or can be extended to support custom persistence of the information via
a public interface).
* Support for JDBC-4 (See http://DBC-4.ora-code.com).0 NCHAR, NVARCHAR and NCLOB types.
* The driver will automatically adjust the server session variable "net_write
_timeout" when it determines its been asked for a "streaming" result, and resets
it to the previous value when the result set has been consumed. (The
configuration property is named "netTimeoutForStreamingResults", with a unit of
seconds, the value '0' means the driver will not try and adjust this value).
* Added experimental support for statement "interceptors" via the com
.mysql.jdbc.StatementInterceptor interface, examples are in com/mysql/jdbc
/interceptors. Implement this interface to be placed "in between" query
execution, so that it can be influenced (currently experimental).
* The data (and how it's stored) for ResultSet rows are now behind an
interface which allows us (in some cases) to allocate less memory per row, in
that for "streaming" result sets, we re-use the packet used to read rows, since
only one row at a time is ever active.
* The driver now picks appropriate internal row representation (whole row in
one buffer, or individual byte[]s for each column value) depending on
heuristics, including whether or not the row has BLOB or TEXT types and the
overall row-size. The threshold for row size that will cause the driver to use
a buffer rather than individual byte[]s is configured by the configuration
property "largeRowSizeThreshold", which has a default value of 2KB.
* Setting "rewriteBatchedStatements" to "true" now causes CallableStatements
with batched arguments to be re-written in the form "CALL (...); CALL (...); ..
." to send the batch in as few client-server round trips as possible.
This release also includes the following changes that are also present in
Connector/J 5.0.8 (not yet released):
* Fixed BUG#30550, executeBatch() would fail with an ArithmeticException and/or
NullPointerException when the batch had zero members and
"rewriteBatchedStatements" was set to "true" for the connection.
* Added two configuration parameters (both default to "false")
* blobsAreStrings - Should the driver always treat BLOBs as Strings
specifically to work around dubious metadata returned by the server for GROUP
BY clauses?
* functionsNeverReturnBlobs - Should the driver always treat data from
functions returning BLOBs as Strings -
specifically to work around dubious metadata
returned by the server for GROUP BY clauses?
* Fixed BUG#29106 - Connection checker for JBoss didn't use same method
parameters via reflection, causing connections to always seem "bad".
* Fixed BUG#30664 - Note that this fix only works for MySQL server versions 5.0
.25 and newer, since earlier versions didn't consistently return correct
metadata for functions, and thus results from subqueries and functions were
indistinguishable from each other, leading to type-related bugs.
* Fixed BUG#28972 - DatabaseMetaData.getTypeInfo() for the types DECIMAL and
NUMERIC will return a precision of 254 for server versions older than 5.0.3, 64
for versions 5.0.3-5.0.5 and 65 for versions newer than 5.0.5.
* Fixed BUG#29852 - Closing a load-balanced connection would cause a
ClassCastException.
* Fixed BUG#27867 - Schema objects with identifiers other than the connection
character aren't retrieved correctly in ResultSetMetadata.
* Fixed BUG#28689 - CallableStatement.executeBatch() doesn't work when
connection property "noAccessToProcedureBodies" has been set to "true".
The fix involves changing the behavior of "noAccessToProcedureBodies",in that
the driver will now report all paramters as "IN" paramters but allow callers to
call registerOutParameter() on them without throwing an exception.
* Fixed BUG#27182 - Connection.getServerCharacterEncoding() doesn't work for
servers with version >= 4.1.
* Fixed BUG#27915 - DatabaseMetaData.getColumns() doesn't contain SCOPE_* or IS
_AUTOINCREMENT columns.
* Fixed BUG#30851, NPE with null column values when "padCharsWithSpace" is set
to "true".
* Specifying a "validation query" in your connection pool that starts with "/*
ping */" _exactly_ will cause the driver to instead send a ping to the server
and return a fake result set (much lighter weight), and when using a
ReplicationConnection or a LoadBalancedConnection, will send the ping across
all active connections.
* Fixed Bug#30892 setObject(int, Object, int, int) delegate in
PreparedStatmentWrapper delegates to wrong method.
Enjoy!
-Mark
- --
Mark Matthews, Architect (Client Connectivity)
MySQL, Inc. Chicago, USA - www.mysql.com
-- --BEGIN PGP SIGNATURE-- --
Version: GnuPG v1.4.6 (MingW32)
iD8DBQFG5Yo0tvXNTca6JD8RAqurAJ4pX5wWRp1sfnT7Pu4GmfS+UGpXSwCgiOAM
/EqCA+euqViUxJAmgVjz6Bo=vgf2
-- --END PGP SIGNATURE-- --
--
MySQL Announce Mailing List
For list archives: http://lists.mysql.com/announce
To unsubscribe: http://lists.mysql.com/announce?unsub=mysql@(protected)
|
|
|