db-derby-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From chaa...@apache.org
Subject svn commit: r1594093 - /db/derby/docs/trunk/src/ref/rrefsqlj13590.dita
Date Mon, 12 May 2014 21:01:25 GMT
Author: chaase3
Date: Mon May 12 21:01:25 2014
New Revision: 1594093

URL: http://svn.apache.org/r1594093
Log:
DERBY-6527  Fix errors in foreign keys documentation

Modified a Reference Manual topic.

Patch: DERBY-6527-3.diff

Modified:
    db/derby/docs/trunk/src/ref/rrefsqlj13590.dita

Modified: db/derby/docs/trunk/src/ref/rrefsqlj13590.dita
URL: http://svn.apache.org/viewvc/db/derby/docs/trunk/src/ref/rrefsqlj13590.dita?rev=1594093&r1=1594092&r2=1594093&view=diff
==============================================================================
--- db/derby/docs/trunk/src/ref/rrefsqlj13590.dita (original)
+++ db/derby/docs/trunk/src/ref/rrefsqlj13590.dita Mon May 12 21:01:25 2014
@@ -191,15 +191,22 @@ foreign key relationships intact when a 
 from a table.</p> <p>You specify the update and delete rule of a referential
 constraint when you define the referential constraint.</p> <p>The update rule
 applies when a row of either the parent or dependent table is updated. The
-choices are NO ACTION and RESTRICT. </p> <p>When a value in a column of the
+choices are NO ACTION and RESTRICT. </p> 
+<ul>
+<li>When a value in a column of the
 parent table's primary key is updated and the update rule has been specified
 as RESTRICT, <ph conref="../conrefs.dita#prod/productshortname"></ph> checks
 dependent tables for foreign key constraints. If any row in a dependent table
-violates a foreign key constraint, the transaction is rolled back. </p> <p>If
+violates a foreign key constraint, the statement is rolled back. </li>
+<li>If
 the update rule is NO ACTION, <ph conref="../conrefs.dita#prod/productshortname"></ph>
checks
-the dependent tables for foreign key constraints <i>after</i> all updates
-have been executed but <i>before</i> triggers have been executed. If any row
-in a dependent table violates a foreign key constraint, the statement is rejected.</p>
<p>When
+the dependent tables for foreign key constraints <i>after</i> all updates and
+BEFORE triggers have been executed, but <i>before</i> AFTER triggers have been
+executed. If any row
+in a dependent table violates a foreign key constraint, the statement is
+rejected.</li>
+</ul>
+<p>When
 a value in a column of the dependent table is updated, and that value is part
 of a foreign key, NO ACTION is the implicit update rule. NO ACTION means that
 if a foreign key is updated with a non-null value, the update value must match
@@ -207,23 +214,33 @@ a value in the parent table's primary ke
 If the update does not match a value in the parent table's primary key, the
 statement is rejected.</p> <p>The delete rule applies when a row of the parent
 table is deleted and that row has dependents in the dependent table of the
-referential constraint. If rows of the dependent table are deleted, the delete
+referential constraint. If rows of the dependent table are deleted as part of a
+CASCADE on the parent table, the delete
 operation on the parent table is said to be <i>propagated</i> to the dependent
 table. If the dependent table is also a parent table, the action specified
 applies, in turn, to its dependents. </p> <p>The choices are NO ACTION, RESTRICT,
 CASCADE, or SET NULL. SET NULL can be specified only if some column of the
-foreign key allows null values.</p> <p>If the delete rule is:</p> <p>NO
ACTION, <ph
+foreign key allows null values. If the delete rule is:</p> 
+<ul>
+<li>NO ACTION, <ph
 conref="../conrefs.dita#prod/productshortname"></ph> checks the dependent
-tables for foreign key constraints <i>after</i> all deletes have been executed
-but <i>before</i> triggers have been executed. If any row in a dependent table
-violates a foreign key constraint, the statement is rejected.</p> <p>RESTRICT,
<ph
+tables for foreign key constraints <i>after</i> all deletes and BEFORE triggers
+have been executed, but <i>before</i> AFTER triggers have been executed. If any
+row in a dependent table violates a foreign key constraint, the statement is
+rejected.</li>
+<li>RESTRICT, <ph
 conref="../conrefs.dita#prod/productshortname"></ph> checks dependent tables
 for foreign key constraints. If any row in a dependent table violates a foreign
-key constraint, the transaction is rolled back.</p> <p>CASCADE, the delete
+key constraint, the statement is rolled back.</li>
+<li>CASCADE, the delete
 operation is propagated to the dependent table (and that table's dependents,
-if applicable).</p> <p>SET NULL, each nullable column of the dependent table's
-foreign key is set to null. (Again, if the dependent table also has dependent
-tables, nullable columns in those tables' foreign keys are also set to null.)</p> <p>Each
+if applicable).</li>
+<li>SET NULL, each nullable column of the dependent table's
+foreign key is set to null.</li>
+</ul>
+<p>When a value in a column of the dependent table is deleted, and that value is
+part of a foreign key, NO ACTION is the implicit delete rule.</p>
+<p>Each
 referential constraint in which a table is a parent has its own delete rule;
 all applicable delete rules are used to determine the result of a delete operation.
 Thus, a row cannot be deleted if it has dependents in a referential constraint
@@ -245,6 +262,10 @@ when a parent table is the object of a d
 <li>If the dependent table is also a parent table, the actions described in
 this list apply, in turn, to its dependents.</li>
 </ul></p> </section>
+<section><title>Statement dependency system</title> <p>INSERT
+and UPDATE statements depend on all constraints on the target table. DELETEs
+depend on unique, primary key, and foreign key constraints. These statements
+are invalidated if a constraint is added to or dropped from the target table.</p> </section>
 <example id="sqljidx6080"><title>Examples</title> <codeblock><b>--
column-level primary key constraint named OUT_TRAY_PK:
 CREATE TABLE SAMP.OUT_TRAY
 	(
@@ -332,10 +353,6 @@ CREATE TABLE CONDOS
 	CITY_ID INT CONSTRAINT city_foreign_key
 	REFERENCES Cities ON DELETE CASCADE ON UPDATE RESTRICT
 	);</b></codeblock> </example>
-<section><title>Statement dependency system</title> <p>INSERT
-and UPDATE statements depend on all constraints on the target table. DELETEs
-depend on unique, primary key, and foreign key constraints. These statements
-are invalidated if a constraint is added to or dropped from the target table.</p> </section>
 </refbody>
 </reference>
 



Mime
View raw message