List:Commits« Previous MessageNext Message »
From:jon.stephens Date:April 29 2011 9:28am
Subject:svn commit - mysqldoc@oter02: r26086 - in trunk: dynamic-docs/changelog refman-5.1
View as plain text  
Author: js221926
Date: 2011-04-29 11:28:39 +0200 (Fri, 29 Apr 2011)
New Revision: 26086

Log:

Wording fixes -- should refer to deferring checking of constraints



Modified:
   trunk/dynamic-docs/changelog/mysqld-2.xml
   trunk/refman-5.1/mysql-cluster-replication-core.xml


Modified: trunk/dynamic-docs/changelog/mysqld-2.xml
===================================================================
--- trunk/dynamic-docs/changelog/mysqld-2.xml	2011-04-29 08:54:49 UTC (rev 26085)
+++ trunk/dynamic-docs/changelog/mysqld-2.xml	2011-04-29 09:28:39 UTC (rev 26086)
Changed blocks: 1, Lines Added: 8, Lines Deleted: 8; 1624 bytes

@@ -36,18 +36,18 @@
       <para>
         To keep this from happening, unique keys are now updated in
         deferred mode, meaning that all table rows are updated before
-        any unique indexes are updated. Thus, the order of the row
+        any unique indexes are checked. Thus, the order of the row
         updates is no longer important.
       </para>
 
       <para>
-        You should be aware that deferring unique keys in this way is
-        currently supported only by <literal role="se">NDB</literal>,
-        and thus only for replication between NDB tables on both the
-        master and the slave. You cannot replicate updates of unique
-        keys successfully when replicating from
-        <literal role="se">NDB</literal> to a different storage engine
-        such as <literal role="se">MyISAM</literal> or
+        You should be aware that deferring constraint checking in this
+        way is currently supported only by
+        <literal role="se">NDB</literal>, and thus only for replication
+        between NDB tables on both the master and the slave. You cannot
+        replicate updates of unique keys successfully when replicating
+        from <literal role="se">NDB</literal> to a different storage
+        engine such as <literal role="se">MyISAM</literal> or
         <literal role="se">InnoDB</literal>.
       </para>
 


Modified: trunk/refman-5.1/mysql-cluster-replication-core.xml
===================================================================
--- trunk/refman-5.1/mysql-cluster-replication-core.xml	2011-04-29 08:54:49 UTC (rev 26085)
+++ trunk/refman-5.1/mysql-cluster-replication-core.xml	2011-04-29 09:28:39 UTC (rev 26086)
Changed blocks: 3, Lines Added: 8, Lines Deleted: 8; 2172 bytes

@@ -653,13 +653,13 @@
         <para>
           In MySQL Cluster NDB 7.0.25, MySQL Cluster NDB 7.1.14, and
           later, this issue is solved for replication between
-          <literal role="se">NDB</literal> tables by deferring updates
-          of unique keys until after table row updates have been
+          <literal role="se">NDB</literal> tables by deferring unique
+          key checks until after all table row updates have been
           performed.
         </para>
 
         <para>
-          Deferring unique keys in this way is currently supported only
+          Deferring contraints in this way is currently supported only
           by <literal role="se">NDB</literal>. Thus, updates of unique
           keys when replicating from <literal role="se">NDB</literal> to
           a different storage engine such as

@@ -669,7 +669,7 @@
 
         <para>
           The problem encountered when replicating without deferred
-          application of unique key updates can be illustrated using
+          checking of unique key updates can be illustrated using
           <literal role="se">NDB</literal> table such as
           <literal>t</literal>, is created and populated on the master
           (and replicated to a slave that does not support deferred

@@ -700,10 +700,10 @@
 </programlisting>
 
         <para>
-          However, the same statement failed with a constraint violation
-          or duplicate key error on the slave, because the ordering of
-          the row updates was done for one partition at a time, rather
-          than for the table as a whole.
+          However, the same statement failed with a duplicate key error
+          or other constraint violation on the slave, because the
+          ordering of the row updates was done for one partition at a
+          time, rather than for the table as a whole.
         </para>
 
         <note>


Thread
svn commit - mysqldoc@oter02: r26086 - in trunk: dynamic-docs/changelog refman-5.1jon.stephens29 Apr