Author: mcbrown
Date: 2007-06-29 17:22:18 +0200 (Fri, 29 Jun 2007)
New Revision: 6957
Log:
Syncing 5.1.2 changelog
Updating connector properties
Modified:
trunk/refman-common/connector-j-connprops.xml
trunk/refman-common/news-connector-j.xml
Modified: trunk/refman-common/connector-j-connprops.xml
===================================================================
--- trunk/refman-common/connector-j-connprops.xml 2007-06-29 14:00:53 UTC (rev 6956)
+++ trunk/refman-common/connector-j-connprops.xml 2007-06-29 15:22:18 UTC (rev 6957)
Changed blocks: 4, Lines Added: 22, Lines Deleted: 3; 2777 bytes
@@ -554,6 +554,14 @@
<entry>3.1.7</entry>
</row>
<row>
+ <entry>largeRowSizeThreshold</entry>
+ <entry>What size result set row should the JDBC driver consider "large", and
+ thus use a more memory-efficient way of representing the
+ row internally?</entry>
+ <entry>2048</entry>
+ <entry>5.1.1</entry>
+ </row>
+ <row>
<entry>loadBalanceStrategy</entry>
<entry>If using a load-balanced connection to connect to SQL nodes in a MySQL
Cluster/NDB configuration (by using the URL prefix
@@ -601,6 +609,14 @@
<entry>3.1.13</entry>
</row>
<row>
+ <entry>useDirectRowUnpack</entry>
+ <entry>Use newer result set row unpacking code that skips a copy from network
+ buffers to a MySQL packet instance and instead reads
+ directly into the result set row data buffers.</entry>
+ <entry>true</entry>
+ <entry>5.1.1</entry>
+ </row>
+ <row>
<entry>useDynamicCharsetInfo</entry>
<entry>Should the driver use a per-connection cache of character set
information queried from the server when necessary, or
@@ -677,8 +693,10 @@
</row>
<row>
<entry>logger</entry>
- <entry>The name of a class that implements ${0} that will be used to log
- messages to. (default is ${1}, which logs to STDERR)</entry>
+ <entry>The name of a class that implements "com.mysql.jdbc.log.Log" that will
+ be used to log messages to. (default is
+ "com.mysql.jdbc.log.StandardLogger", which logs to
+ STDERR)</entry>
<entry>com.mysql.jdbc.log.StandardLogger</entry>
<entry>3.1.1</entry>
</row>
@@ -1335,7 +1353,8 @@
<entry>zeroDateTimeBehavior</entry>
<entry>What should happen when the driver encounters DATETIME values that are
composed entirely of zeroes (used by MySQL to represent
- invalid dates)? Valid values are ${0}, ${1} and ${2}.</entry>
+ invalid dates)? Valid values are "exception", "round"
+ and "convertToNull".</entry>
<entry>exception</entry>
<entry>3.1.4</entry>
</row>
Modified: trunk/refman-common/news-connector-j.xml
===================================================================
--- trunk/refman-common/news-connector-j.xml 2007-06-29 14:00:53 UTC (rev 6956)
+++ trunk/refman-common/news-connector-j.xml 2007-06-29 15:22:18 UTC (rev 6957)
Changed blocks: 1, Lines Added: 205, Lines Deleted: 0; 8149 bytes
@@ -13,11 +13,216 @@
<title>Changes in MySQL Connector/J 5.1.x</title>
+ <section id="cj-news-5-1-2">
+
+ <title>Changes in MySQL Connector/J 5.1.2 (29 June 2007)</title>
+
+ <para role="release-level">
+ This is a new Beta development release, fixing recently
+ discovered bugs.
+ </para>
+
+ <para>
+ Functionality added or changed:
+ </para>
+
+ <itemizedlist>
+
+ <listitem>
+ <para>
+ Setting the configuration property
+ <literal>rewriteBatchedStatements</literal> to
+ <literal>true</literal> will now cause the driver to rewrite
+ batched prepared statements with more than 3 parameter sets
+ in a batch into multi-statements (separated by ";") if they
+ are not plain <literal> (i.e. without
+ <literal>SELECT</literal> or <literal>ON DUPLICATE KEY
+ UPDATE</literal> clauses) INSERT </literal> or
+ <literal>REPLACE</literal> statements.
+ </para>
+ </listitem>
+
+ </itemizedlist>
+
+ </section>
+
+ <section id="cj-news-5-1-1">
+
+ <title>Changes in MySQL Connector/J 5.1.1 (22 June 2007)</title>
+
+ <para role="release-level">
+ This is a new Alpha development release, adding new features and
+ fixing recently discovered bugs.
+ </para>
+
+ <para>
+ Functionality added or changed:
+ </para>
+
+ <itemizedlist>
+
+ <listitem>
+ <para>
+ Pulled vendor-extension methods of
+ <literal>Connection</literal> implementation out into an
+ interface to support <literal>java.sql.Wrapper</literal>
+ functionality from
+ <literal>ConnectionPoolDataSource</literal>. The vendor
+ extensions are javadoc'd in the
+ <literal>com.mysql.jdbc.Connection</literal> interface.
+ </para>
+
+ <para>
+ For those looking further into the driver implementation, it
+ is not an API that is used for plugability of
+ implementations inside our driver (which is why there are
+ still references to <literal>ConnectionImpl</literal>
+ throughout the code).
+ </para>
+
+ <para>
+ We've also added server and client
+ <literal>prepareStatement()</literal> methods that cover all
+ of the variants in the JDBC API.
+ </para>
+
+ <para>
+ <emphasis role="bold">Incompatible change</emphasis>:
+ <literal>Connection.serverPrepare(String)</literal> has been
+ re-named to
+ <literal>Connection.serverPrepareStatement()</literal> for
+ consistency with
+ <literal>Connection.clientPrepareStatement()</literal>.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Similar to <literal>Connection</literal>, we pulled out
+ vendor extensions to <literal>Statement</literal> into an
+ interface named <literal>com.mysql.Statement</literal>, and
+ moved the <literal>Statement</literal> class into
+ <literal>com.mysql.StatementImpl</literal>. The two methods
+ (javadoc'd in <literal>com.mysql.Statement</literal> are
+ <literal>enableStreamingResults()</literal>, which already
+ existed, and <literal>disableStreamingResults()</literal>
+ which sets the statement instance back to the fetch size and
+ result set type it had before
+ <literal>enableStreamingResults()</literal> was called.
+ </para>
+ </listitem>
+
+ <listitem>
+ <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>.
+ </para>
+
+ <para>
+ Implement this interface to be placed "in between" query
+ execution, so that you can influence it. (currently
+ experimental).
+ </para>
+
+ <para>
+ <literal>StatementInterceptors</literal> are "chainable"
+ when configured by the user, the results returned by the
+ "current" interceptor will be passed on to the next on in
+ the chain, from left-to-right order, as specified by the
+ user in the JDBC configuration property
+ <literal>statementInterceptors</literal>.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ See the sources (fully javadoc'd) for
+ <literal>com.mysql.jdbc.StatementInterceptor</literal> for
+ more details until we iron out the API and get it documented
+ in the manual.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Externalized the descriptions of connection properties.
+ </para>
+ </listitem>
+
+ <listitem>
+ <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>
+ </listitem>
+
+ <listitem>
+ <para>
+ Made it possible to retrieve prepared statement parameter
+ bindings (to be used in
+ <literal>StatementInterceptors</literal>, primarily).
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Row navigation now causes any streams/readers open on the
+ result set to be closed, as in some cases we're reading
+ directly from a shared network packet and it will be
+ overwritten by the "next" row.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Setting <literal>rewriteBatchedStatements</literal> to
+ <literal>true</literal> now causes
+ <literal>CallableStatements</literal> with batched arguments
+ to be re-written in the form <literal>CALL (...); CALL
+ (...); ...</literal> to send the batch in as few
+ client-server round trips as possible.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ 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
+ <literal>largeRowSizeThreshold</literal>, which has a
+ default value of 2KB.
+ </para>
+ </listitem>
+
+ </itemizedlist>
+
+ </section>
+
<section id="cj-news-5-1-0">
<title>Changes in MySQL Connector/J 5.1.0 (11 April 2007)</title>
<para>
+ This is the first public alpha release of the current
+ Connector/J 5.1 development branch, providing an insight to
+ upcoming features. Although some of these are still under
+ development, this release includes the following new features
+ and changes (in comparison to the current Connector/J 5.0
+ production release):
+ </para>
+
+ <para>
<emphasis role="bold">Important change:</emphasis> Due to a
number of issues with the use of server-side prepared
statements, Connector/J 5.0.5 has disabled their use by default.
| Thread |
|---|
| • svn commit - mysqldoc@docsrva: r6957 - trunk/refman-common | mcbrown | 29 Jun |
