svn commit - mysqldoc@docsrva: r9984 - in trunk: . refman-4.1 refman-5.0 refman-5.1 refman-6.0

[paul]

Author: paul
Date: 2008-02-22 19:51:47 +0100 (Fri, 22 Feb 2008)
New Revision: 9984

Log:
 r29583@arctic:  paul | 2008-02-22 12:42:35 -0600
 Additional information about REPLACE with MERGE tables. (Bug#27809)


Modified:
   trunk/refman-4.1/storage-engines.xml
   trunk/refman-5.0/se-merge.xml
   trunk/refman-5.1/se-merge.xml
   trunk/refman-6.0/se-merge.xml

Property changes on: trunk
___________________________________________________________________
Name: svk:merge
   - 4767c598-dc10-0410-bea0-d01b485662eb:/mysqldoc-local/mysqldoc/trunk:34985
7d8d2c4e-af1d-0410-ab9f-b038ce55645b:/mysqldoc-local/mysqldoc:29435
b5ec3a16-e900-0410-9ad2-d183a3acac99:/mysqldoc-local/mysqldoc/trunk:14218
bf112a9c-6c03-0410-a055-ad865cd57414:/mysqldoc-local/mysqldoc/trunk:29582
   + 4767c598-dc10-0410-bea0-d01b485662eb:/mysqldoc-local/mysqldoc/trunk:34985
7d8d2c4e-af1d-0410-ab9f-b038ce55645b:/mysqldoc-local/mysqldoc:29435
b5ec3a16-e900-0410-9ad2-d183a3acac99:/mysqldoc-local/mysqldoc/trunk:14218
bf112a9c-6c03-0410-a055-ad865cd57414:/mysqldoc-local/mysqldoc/trunk:29583


Modified: trunk/refman-4.1/storage-engines.xml
===================================================================
--- trunk/refman-4.1/storage-engines.xml	2008-02-22 18:51:30 UTC (rev 9983)
+++ trunk/refman-4.1/storage-engines.xml	2008-02-22 18:51:47 UTC (rev 9984)
Changed blocks: 1, Lines Added: 33, Lines Deleted: 1; 1699 bytes

@@ -2163,8 +2163,40 @@
 
         <listitem>
           <para>
-            <literal>REPLACE</literal> does not work.
+            <literal>REPLACE</literal> does not work as expected because
+            the <literal>MERGE</literal> engine cannot enforce
+            uniqueness over the set of underlying tables. The two key
+            facts are:
           </para>
+
+          <itemizedlist>
+
+            <listitem>
+              <para>
+                <literal>REPLACE</literal> can detect unique key
+                violations only in the underlying table to which it is
+                going to write (which is determined by
+                <literal>INSERT_METHOD</literal>). This differs from
+                violations in the <literal>MERGE</literal> table itself.
+              </para>
+            </listitem>
+
+            <listitem>
+              <para>
+                If <literal>REPLACE</literal> detects such a violation,
+                it will only change the corresponding row in the first
+                underlying table in which the row is present, whereas a
+                row with the same unique key value may present in all
+                underlying tables.
+              </para>
+            </listitem>
+
+          </itemizedlist>
+
+          <para>
+            Similar considerations apply for <literal>INSERT ... ON
+            DUPLICATE KEY UPDATE</literal>.
+          </para>
         </listitem>
 
         <listitem>


Modified: trunk/refman-5.0/se-merge.xml
===================================================================
--- trunk/refman-5.0/se-merge.xml	2008-02-22 18:51:30 UTC (rev 9983)
+++ trunk/refman-5.0/se-merge.xml	2008-02-22 18:51:47 UTC (rev 9984)
Changed blocks: 1, Lines Added: 32, Lines Deleted: 1; 1598 bytes

@@ -527,8 +527,39 @@
 
       <listitem>
         <para>
-          <literal>REPLACE</literal> does not work.
+          <literal>REPLACE</literal> does not work as expected because
+          the <literal>MERGE</literal> engine cannot enforce uniqueness
+          over the set of underlying tables. The two key facts are:
         </para>
+
+        <itemizedlist>
+
+          <listitem>
+            <para>
+              <literal>REPLACE</literal> can detect unique key
+              violations only in the underlying table to which it is
+              going to write (which is determined by
+              <literal>INSERT_METHOD</literal>). This differs from
+              violations in the <literal>MERGE</literal> table itself.
+            </para>
+          </listitem>
+
+          <listitem>
+            <para>
+              If <literal>REPLACE</literal> detects such a violation, it
+              will only change the corresponding row in the first
+              underlying table in which the row is present, whereas a
+              row with the same unique key value may present in all
+              underlying tables.
+            </para>
+          </listitem>
+
+        </itemizedlist>
+
+        <para>
+          Similar considerations apply for <literal>INSERT ... ON
+          DUPLICATE KEY UPDATE</literal>.
+        </para>
       </listitem>
 
       <listitem>


Modified: trunk/refman-5.1/se-merge.xml
===================================================================
--- trunk/refman-5.1/se-merge.xml	2008-02-22 18:51:30 UTC (rev 9983)
+++ trunk/refman-5.1/se-merge.xml	2008-02-22 18:51:47 UTC (rev 9984)
Changed blocks: 1, Lines Added: 32, Lines Deleted: 1; 1598 bytes

@@ -510,8 +510,39 @@
 
       <listitem>
         <para>
-          <literal>REPLACE</literal> does not work.
+          <literal>REPLACE</literal> does not work as expected because
+          the <literal>MERGE</literal> engine cannot enforce uniqueness
+          over the set of underlying tables. The two key facts are:
         </para>
+
+        <itemizedlist>
+
+          <listitem>
+            <para>
+              <literal>REPLACE</literal> can detect unique key
+              violations only in the underlying table to which it is
+              going to write (which is determined by
+              <literal>INSERT_METHOD</literal>). This differs from
+              violations in the <literal>MERGE</literal> table itself.
+            </para>
+          </listitem>
+
+          <listitem>
+            <para>
+              If <literal>REPLACE</literal> detects such a violation, it
+              will only change the corresponding row in the first
+              underlying table in which the row is present, whereas a
+              row with the same unique key value may present in all
+              underlying tables.
+            </para>
+          </listitem>
+
+        </itemizedlist>
+
+        <para>
+          Similar considerations apply for <literal>INSERT ... ON
+          DUPLICATE KEY UPDATE</literal>.
+        </para>
       </listitem>
 
       <listitem>


Modified: trunk/refman-6.0/se-merge.xml
===================================================================
--- trunk/refman-6.0/se-merge.xml	2008-02-22 18:51:30 UTC (rev 9983)
+++ trunk/refman-6.0/se-merge.xml	2008-02-22 18:51:47 UTC (rev 9984)
Changed blocks: 1, Lines Added: 32, Lines Deleted: 1; 1598 bytes

@@ -508,8 +508,39 @@
 
       <listitem>
         <para>
-          <literal>REPLACE</literal> does not work.
+          <literal>REPLACE</literal> does not work as expected because
+          the <literal>MERGE</literal> engine cannot enforce uniqueness
+          over the set of underlying tables. The two key facts are:
         </para>
+
+        <itemizedlist>
+
+          <listitem>
+            <para>
+              <literal>REPLACE</literal> can detect unique key
+              violations only in the underlying table to which it is
+              going to write (which is determined by
+              <literal>INSERT_METHOD</literal>). This differs from
+              violations in the <literal>MERGE</literal> table itself.
+            </para>
+          </listitem>
+
+          <listitem>
+            <para>
+              If <literal>REPLACE</literal> detects such a violation, it
+              will only change the corresponding row in the first
+              underlying table in which the row is present, whereas a
+              row with the same unique key value may present in all
+              underlying tables.
+            </para>
+          </listitem>
+
+        </itemizedlist>
+
+        <para>
+          Similar considerations apply for <literal>INSERT ... ON
+          DUPLICATE KEY UPDATE</literal>.
+        </para>
       </listitem>
 
       <listitem>