Author: jstephens
Date: 2006-06-19 19:56:17 +0200 (Mon, 19 Jun 2006)
New Revision: 2422
Log:
Documenting Cluster bugfixes:
Bug #18966, Bug #19285, Bug #19872,
Bug #19932, Bug #20016, Bug #20073
Modified:
trunk/ndbapi/ndb-classes.xml
trunk/refman-common/news-5.0.xml
trunk/refman-common/news-5.1.xml
Modified: trunk/ndbapi/ndb-classes.xml
===================================================================
--- trunk/ndbapi/ndb-classes.xml 2006-06-19 17:35:28 UTC (rev 2421)
+++ trunk/ndbapi/ndb-classes.xml 2006-06-19 17:56:17 UTC (rev 2422)
@@ -1905,31 +1905,39 @@
<para>
<literal>NdbOperation::insertTuple()</literal> must use
<literal>NdbBlob::setValue()</literal> if the
- <literal>BLOB</literal> column is non-nullable.
+ <literal>BLOB</literal> attribute is non-nullable.
</para>
</listitem>
<listitem>
<para>
- <literal>NdbOperation::readTuple()</literal> used with an
- exclusive lock can also update an existing value.
+ <literal>NdbOperation::readTuple()</literal> used with any
+ lock mode can read but not write blob values.
</para>
+
+ <para>
+ When the <literal>LM_CommittedRead</literal> lock mode is
+ used with <literal>readTuple()</literal>, the lock mode is
+ automatically upgraded to <literal>LM_Read</literal>
+ whenever blob attributes are accessed.
+ </para>
</listitem>
<listitem>
<para>
- <literal>NdbOperation::updateTuple()</literal> can
- overwrite or update an existing value using
- <literal>NdbBlob::setValue()</literal>.
+ <literal>NdbOperation::updateTuple()</literal> can either
+ overwrite an existing value using
+ <literal>NdbBlob::setValue()</literal>, or update it
+ during the active phase.
</para>
</listitem>
<listitem>
<para>
<literal>NdbOperation::writeTuple()</literal> always
- overwrites, and must use
+ overwrites blob values, and must use
<literal>NdbBlob::setValue()</literal> if the
- <literal>BLOB</literal> column is non-nullable.
+ <literal>BLOB</literal> attribute is non-nullable.
</para>
</listitem>
@@ -1939,18 +1947,33 @@
implicit, non-accessible <literal>BLOB</literal> handles.
</para>
</listitem>
-
+
<listitem>
<para>
- A scan with an exclusive lock can also update an existing
- value.
+ A scan with any lock mode can use its blob handles to read
+ blob values but not write them.
</para>
+
+ <para>
+ A scan using the <literal>LM_Exclusive</literal> lock mode
+ can update row and blob values using
+ <literal>updateCurrentTuple()</literal>; the operation
+ returned must explicitly create its own blob handle.
+ </para>
+
+ <para>
+ A scan using the <literal>LM_Exclusive</literal> lock mode
+ can delete row values (and therefore blob values) using
+ <literal>deleteCurrentTuple()</literal>; this create
+ implicit non-accessible blob handles.
+ </para>
</listitem>
-
+
<listitem>
<para>
- A scan update operation with lock takeover must perform
- its own <literal>NdbOperation::getBlobHandle()</literal>.
+ An operation which is returned by
+ <literal>lockCurrentTuple()</literal> cannot update blob
+ values.
</para>
</listitem>
@@ -1970,21 +1993,9 @@
working with <literal>NdbBlob</literal> objects:
<itemizedlist>
-
+
<listitem>
<para>
- Lock mode upgrade should be handled automatically.
- </para>
- </listitem>
-
- <listitem>
- <para>
- Lock mode vs. an allowed operation is not checked.
- </para>
- </listitem>
-
- <listitem>
- <para>
Too many pending <literal>BLOB</literal> operations can
overflow the I/O buffers.
</para>
@@ -3391,7 +3402,8 @@
<para>
Use this method to obtain an error object. The error may be
blob-specific or may be copied from a failed implicit
- operation.
+ operation. The error code is copied back to the operation
+ unless the operation already has a non-zero error code.
</para>
</formalpara>
Modified: trunk/refman-common/news-5.0.xml
===================================================================
--- trunk/refman-common/news-5.0.xml 2006-06-19 17:35:28 UTC (rev 2421)
+++ trunk/refman-common/news-5.0.xml 2006-06-19 17:56:17 UTC (rev 2422)
@@ -335,6 +335,45 @@
<listitem>
<para>
+ <literal>NDB Cluster</literal>: An internal formatting error
+ caused some management client error messages to be unreadable.
+ (Bug #20016)
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <literal>NDB Cluster</literal>: Running management client
+ commands while <command>mgmd</command> was in the process of
+ disconnecting could cause the management server to fail. (Bug
+ #19932)
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <literal>NDB Cluster</literal> (NDBAPI): Update operations on
+ blobs were not checked for illegal operations.
+ </para>
+
+ <para>
+ <emphasis role="bold">Note</emphasis>: Read locks with blob update
+ operations are now upgraded from read committed to read
+ shared.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <literal>NDB Cluster</literal>: The management client
+ <literal>ALL STOP</literal> command shut down <command>mgmd</command>
+ processes (as well as <command>ndbd</command> processes). (Bug
+ #18966)
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
<literal>NDB Cluster</literal>: <literal>LOAD DATA
LOCAL</literal> failed to ignore duplicate keys in Cluster
tables. (Bug #19496)
Modified: trunk/refman-common/news-5.1.xml
===================================================================
--- trunk/refman-common/news-5.1.xml 2006-06-19 17:35:28 UTC (rev 2421)
+++ trunk/refman-common/news-5.1.xml 2006-06-19 17:56:17 UTC (rev 2422)
@@ -170,6 +170,65 @@
<listitem>
<para>
+ <literal>NDB Cluster</literal> (Replication): A node failure
+ could send duplicate events, causing a
+ <command>mysqld</command> replicating tables containing
+ <literal>BLOB</literal>s to crash.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <literal>NDB Cluster</literal> (Disk Data):
+ <literal>INFORMATION_SCHEMA.FILES</literal> records for
+ <literal>UNDO</literal> files showed incorrect values in the
+ <literal>EXTENT_SIZE</literal>,
+ <literal>FREE_EXTENTS</literal>, and
+ <literal>TOTAL_EXTENTS</literal> columns. (Bug #20073)
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <literal>NDB Cluster</literal>: An internal formatting error
+ caused some management client error messages to be unreadable.
+ (Bug #20016)
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <literal>NDB Cluster</literal>: Running management client
+ commands while <command>mgmd</command> was in the process of
+ disconnecting could cause the management server to fail. (Bug
+ #19932)
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <literal>NDB Cluster</literal> (NDBAPI): Update operations on
+ blobs were not checked for illegal operations.
+ </para>
+
+ <para>
+ <emphasis role="bold">Note</emphasis>: Read locks with blob update
+ operations are now upgraded from read committed to read
+ shared.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <literal>NDB Cluster</literal>: The management client
+ <literal>ALL STOP</literal> command shut down <command>mgmd</command>
+ processes (as well as <command>ndbd</command> processes). (Bug
+ #18966)
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
Defining a table partitioned by <literal>LIST</literal> with a
single <literal>PARTITION ... VALUES IN (NULL)</literal>
clause could lead to server crashes, particularly with queries
| Thread |
|---|
| • svn commit - mysqldoc@docsrva: r2422 - in trunk: ndbapi refman-common | jon | 19 Jun |
