Author: mcbrown
Date: 2007-09-11 18:49:31 +0200 (Tue, 11 Sep 2007)
New Revision: 7795
Log:
Documenting dev bugs:
Bug #21116
Bug #30917
Bug #27915
Bug #27182
Bug #30892
Bug #30851
Bug #28689
Bug #27867
Modified:
trunk/dynamic-docs/changelog/connector-j.xml
Modified: trunk/dynamic-docs/changelog/connector-j.xml
===================================================================
--- trunk/dynamic-docs/changelog/connector-j.xml 2007-09-11 16:47:42 UTC (rev 7794)
+++ trunk/dynamic-docs/changelog/connector-j.xml 2007-09-11 16:49:31 UTC (rev 7795)
Changed blocks: 7, Lines Added: 610, Lines Deleted: 2; 15063 bytes
@@ -2,6 +2,598 @@
<!DOCTYPE changelog SYSTEM "changelog.dtd">
<changelog>
+ <logentry entrytype="feature">
+
+ <versions>
+
+ <version ver="5.1.3"/>
+
+ </versions>
+
+ <message>
+
+ <para>
+ Setting <option>useBlobToStoreUTF8OutsideBMP</option> to
+ <literal>true</literal> tells the driver to treat
+ <literal>[MEDIUM/LONG]BLOB</literal> columns as
+ <literal>[LONG]VARCHAR</literal> columns holding text encoded in
+ UTF-8 that has characters outside the BMP (4-byte encodings),
+ which MySQL server can't handle natively.
+ </para>
+
+ <para>
+ Set <option>utf8OutsideBmpExcludedColumnNamePattern</option> to
+ a regex so that column names matching the given regex will still
+ be treated as <literal>BLOBs</literal> The regex must follow the
+ patterns used for the <literal>java.util.regex
+ </literal>package. The default is to exclude no columns, and
+ include all columns.
+ </para>
+
+ <para>
+ Set <option>utf8OutsideBmpIncludedColumnNamePattern</option> to
+ specify exclusion rules to
+ utf8OutsideBmpExcludedColumnNamePattern". The regex must follow
+ the patterns used for the <literal>java.util.regex</literal>
+ package.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="feature">
+
+ <versions>
+
+ <version ver="5.1.3"/>
+
+ </versions>
+
+ <message>
+
+ <para>
+ New methods on com.mysql.jdbc.Statement:
+ <literal>setLocalInfileInputStream()</literal> and
+ <literal>getLocalInfileInputStream()</literal>:
+ </para>
+
+ <itemizedlist>
+
+ <listitem>
+ <para>
+ <literal>setLocalInfileInputStream()</literal> sets an
+ <literal>InputStream</literal> instance that will be used to
+ send data to the MySQL server for a <literal>LOAD DATA LOCAL
+ INFILE</literal> statement rather than a
+ <literal>FileInputStream</literal> or
+ <literal>URLInputStream</literal> that represents the path
+ given as an argument to the statement.
+ </para>
+
+ <para>
+ This stream will be read to completion upon execution of a
+ <literal>LOAD DATA LOCAL INFILE</literal> statement, and
+ will automatically be closed by the driver, so it needs to
+ be reset before each call to <literal>execute*()</literal>
+ that would cause the MySQL server to request data to fulfill
+ the request for <literal>LOAD DATA LOCAL INFILE</literal>.
+ </para>
+
+ <para>
+ If this value is set to <literal>NULL</literal>, the driver
+ will revert to using a <literal>FileInputStream</literal> or
+ <literal>URLInputStream</literal> as required.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <literal>getLocalInfileInputStream()</literal> returns the
+ <literal>InputStream</literal> instance that will be used to
+ send data in response to a <literal>LOAD DATA LOCAL
+ INFILE</literal> statement.
+ </para>
+
+ <para>
+ This method returns <literal>NULL</literal> if no such
+ stream has been set via
+ <literal>setLocalInfileInputStream()</literal>.
+ </para>
+ </listitem>
+
+ </itemizedlist>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="feature">
+
+ <versions>
+
+ <version ver="5.1.3"/>
+
+ </versions>
+
+ <message>
+
+ <para>
+ Errors encountered during
+ <literal>Statement</literal>/<literal>PreparedStatement</literal>/<literal>CallableStatement.executeBatch()</literal>
+ when <literal>rewriteBatchStatements</literal> has been set to
+ <literal>true</literal> now return
+ <literal>BatchUpdateExceptions</literal> according to the
+ setting of <literal>continueBatchOnError</literal>.
+ </para>
+
+ <para>
+ If <literal>continueBatchOnError</literal> is set to
+ <literal>true</literal>, the update counts for the "chunk" that
+ were sent as one unit will all be set to
+ <literal>EXECUTE_FAILED</literal>, 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
+ <literal>BatchUpdateException</literal>.
+ </para>
+
+ <para>
+ If <literal>continueBatchOnError</literal> 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 <literal>EXECUTE_FAILED</literal>.
+ </para>
+
+ <para>
+ Since MySQL doesn't return multiple error codes for
+ multiple-statements, or for multi-value
+ <literal>INSERT</literal>/<literal>REPLACE</literal>, it is the
+ application's responsibility to handle determining which item(s)
+ in the "chunk" actually failed.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="feature">
+
+ <versions>
+
+ <version ver="5.1.3"/>
+
+ </versions>
+
+ <message>
+
+ <para>
+ <literal>Statement.setQueryTimeout()</literal>s now affect the
+ entire batch for batched statements, rather than the individual
+ statements that make up the batch.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="feature">
+
+ <versions>
+
+ <version ver="5.1.3"/>
+
+ </versions>
+
+ <message>
+
+ <para>
+ JDBC-4.0 ease-of-development features including
+ auto-registration with the <literal>DriverManager</literal> via
+ the service provider mechanism, standardized Connection validity
+ checks and categorized <literal>SQLExceptions</literal> based on
+ recoverability/retry-ability and class of the underlying error.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="feature">
+
+ <versions>
+
+ <version ver="5.1.3"/>
+
+ </versions>
+
+ <message>
+
+ <para>
+ JDBC-4.0 standardized unwrapping to interfaces that include
+ vendor extensions.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="feature">
+
+ <versions>
+
+ <version ver="5.1.3"/>
+
+ </versions>
+
+ <message>
+
+ <para>
+ Support for JDBC-4.0 XML processing via JAXP interfaces to DOM,
+ SAX and StAX.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="feature">
+
+ <versions>
+
+ <version ver="5.1.3"/>
+
+ </versions>
+
+ <message>
+
+ <para>
+ JDBC-4.0 support for setting per-connection client information
+ (which can be viewed in the comments section of a query via
+ <literal>SHOW PROCESSLIST</literal> on a MySQL server, or can be
+ extended to support custom persistence of the information via a
+ public interface).
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="feature">
+
+ <versions>
+
+ <version ver="5.1.3"/>
+
+ </versions>
+
+ <message>
+
+ <para>
+ Support for JDBC-4.0 <literal>NCHAR</literal>,
+ <literal>NVARCHAR</literal> and <literal>NCLOB</literal> types.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="feature">
+
+ <versions>
+
+ <version ver="5.1.3"/>
+
+ </versions>
+
+ <message>
+
+ <para>
+ The driver will automatically adjust the server session variable
+ <literal>net_write_timeout</literal> 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
+ <option>netTimeoutForStreamingResults</option>, with a unit of
+ seconds, the value '0' means the driver will not try and adjust
+ this value).
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="feature">
+
+ <versions>
+
+ <version ver="5.1.3"/>
+
+ </versions>
+
+ <message>
+
+ <para>
+ Added experimental support for statement "interceptors" via the
+ <literal>com.mysql.jdbc.StatementInterceptor</literal>
+ interface, examples are in
+ <filename>com/mysql/jdbc/interceptors</filename>. Implement this
+ interface to be placed "in between" query execution, so that it
+ can be influenced (currently experimental).
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="feature">
+
+ <versions>
+
+ <version ver="5.1.3"/>
+
+ </versions>
+
+ <message>
+
+ <para>
+ The data (and how it's stored) for <literal>ResultSet</literal>
+ 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.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="feature">
+
+ <versions>
+
+ <version ver="5.1.3"/>
+
+ </versions>
+
+ <message>
+
+ <para>
+ 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 <literal>BLOB</literal> or <literal>TEXT</literal> 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
+ <option>largeRowSizeThreshold</option>, which has a default
+ value of 2KB.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="feature">
+
+ <versions>
+
+ <version ver="5.1.3"/>
+
+ </versions>
+
+ <message>
+
+ <para>
+ Setting <option>rewriteBatchedStatements</option> to
+ <literal>true</literal> 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.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <bugs>
+
+ <fixes bugid="27867"></fixes>
+
+ </bugs>
+
+ <versions>
+
+ <version ver="5.0.8"/>
+
+ <version ver="5.1.3"/>
+
+ </versions>
+
+ <message>
+
+ <para>
+ Schema objects with identifiers other than the connection
+ character aren't retrieved correctly in
+ <literal>ResultSetMetadata</literal>.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <bugs>
+
+ <fixes bugid="28689"></fixes>
+
+ </bugs>
+
+ <versions>
+
+ <version ver="5.0.8"/>
+
+ <version ver="5.1.3"/>
+
+ </versions>
+
+ <message>
+
+ <para>
+ <literal>CallableStatement.executeBatch()</literal> doesn't work
+ when connection property
+ <option>noAccessToProcedureBodies</option> has been set to
+ <literal>true</literal>.
+ </para>
+
+ <para>
+ The fix involves changing the behavior of
+ <option>noAccessToProcedureBodies</option>,in that the driver
+ will now report all paramters as "IN" paramters but allow
+ callers to call registerOutParameter() on them without throwing
+ an exception.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <bugs>
+
+ <fixes bugid="30851"></fixes>
+
+ </bugs>
+
+ <versions>
+
+ <version ver="5.0.8"/>
+
+ <version ver="5.1.3"/>
+
+ </versions>
+
+ <message>
+
+ <para>
+ NPE with null column values when
+ <option>padCharsWithSpace</option> is set to true.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <versions>
+
+ <version ver="5.0.8"/>
+
+ <version ver="5.1.3"/>
+
+ </versions>
+
+ <message>
+
+ <para>
+ 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.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <bugs>
+
+ <fixes bugid="30892"></fixes>
+
+ </bugs>
+
+ <versions>
+
+ <version ver="5.0.8"/>
+
+ <version ver="5.1.3"/>
+
+ </versions>
+
+ <message>
+
+ <para>
+ <literal>setObject(int, Object, int, int)</literal> delegate in
+ PreparedStatmentWrapper delegates to wrong method.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <bugs>
+
+ <fixes bugid="27182"></fixes>
+
+ </bugs>
+
+ <versions>
+
+ <version ver="5.0.8"/>
+
+ <version ver="5.1.3"/>
+
+ </versions>
+
+ <message>
+
+ <para>
+ <literal>Connection.getServerCharacterEncoding()</literal>
+ doesn't work for servers with version >= 4.1.
+ </para>
+
+ </message>
+
+ </logentry>
+
+ <logentry entrytype="bug">
+
+ <bugs>
+
+ <fixes bugid="27915"/>
+
+ </bugs>
+
+ <versions>
+
+ <version ver="5.0.8"/>
+
+ <version ver="5.1.3"/>
+
+ </versions>
+
+ <message>
+
+ <para>
+ <literal>DatabaseMetaData.getColumns()</literal> doesn't contain
+ <literal>SCOPE_*</literal> or
+ <literal>IS_AUTOINCREMENT</literal> columns.
+ </para>
+
+ </message>
+
+ </logentry>
+
<logentry entrytype="bug" >
<bugs>
@@ -8087,6 +8679,8 @@
<version ver="5.0.8"/>
+ <version ver="5.1.3"/>
+
</versions>
<message>
@@ -9742,6 +10336,8 @@
<version ver="5.0.8"/>
+ <version ver="5.1.3"/>
+
</versions>
<message>
@@ -10968,6 +11564,8 @@
<version ver="5.0.8"/>
+ <version ver="5.1.3"/>
+
</versions>
<message>
@@ -11786,14 +12384,20 @@
<version ver="5.0.8"/>
+ <version ver="5.1.3"/>
+
</versions>
<message>
<para>
An <literal>ArithmeticException</literal> or
- <literal>NullPointerException</literal> when the batch had zero
- members and <literal>rewriteBatchedStatements=true</literal>.
+ <literal>NullPointerException</literal> would be raised when the
+ batch had zero members and
+ <literal>rewriteBatchedStatements=true</literal> when
+ <literal>addBatch()</literal> was never called, or
+ <literal>executeBatch()</literal> was called immediately after
+ <literal>clearBatch()</literal>.
</para>
</message>
@@ -13014,6 +13618,8 @@
<version ver="5.0.8"/>
+ <version ver="5.1.3"/>
+
</versions>
<message>
@@ -21732,6 +22338,8 @@
<version ver="5.0.8"/>
+ <version ver="5.1.3"/>
+
</versions>
<message>
| Thread |
|---|
| • svn commit - mysqldoc@docsrva: r7795 - trunk/dynamic-docs/changelog | mcbrown | 11 Sep |
