aboutsummaryrefslogtreecommitdiff
path: root/doc
diff options
context:
space:
mode:
authorBoris Kolpackov <boris@codesynthesis.com>2013-04-08 11:13:51 +0200
committerBoris Kolpackov <boris@codesynthesis.com>2013-04-10 18:46:44 +0200
commita4f25daf17392c9c4b90de60b9d777290706f667 (patch)
treee3b4903ac35eb2ec4c44cfc7ce630f5d964c7b3d /doc
parent2fa6a4d00945866e62d980270d5807f3abca75ab (diff)
Generate add/drop foreign key migration statements
Also add the --fkeys-deferrable-mode option. General schemas generation rework.
Diffstat (limited to 'doc')
-rw-r--r--doc/manual.xhtml70
1 files changed, 52 insertions, 18 deletions
diff --git a/doc/manual.xhtml b/doc/manual.xhtml
index e9471fd..dad3c90 100644
--- a/doc/manual.xhtml
+++ b/doc/manual.xhtml
@@ -16046,9 +16046,16 @@ namespace odb
committed. The only behaviors supported by MySQL are to either
check such constraints immediately (InnoDB engine) or to ignore
foreign key constraints altogether (all other engines). As a
- result, schemas generated by the ODB compiler for MySQL have
- foreign key definitions commented out. They are retained only
- for documentation.</p>
+ result, by default, schemas generated by the ODB compiler for
+ MySQL have foreign key definitions commented out. They are
+ retained only for documentation.</p>
+
+ <p>You can override the default behavior and instruct the ODB
+ compiler to generate non-deferrable foreign keys by specifying
+ the <code>--fkeys-deferrable-mode not_deferrable</code> ODB
+ compiler option. Note, however, that in this case the order in
+ which you persist, update, and erase objects within a transaction
+ becomes important.</p>
<h2><a name="15.6">15.6 MySQL Index Definitions</a></h2>
@@ -16909,14 +16916,14 @@ odb::database&amp; db = ...
}
</pre>
- <p>Finally, ODB relies on standard SQL behavior which requires
+ <p>Finally, ODB assumes the standard SQL behavior which requires
that foreign key constraints checking is deferred until the
transaction is committed. Default SQLite behavior is to check such
constraints immediately. As a result, when used with ODB, a custom
- database schema that defines foreign key constraints must declare
- such constraints as <code>DEFERRABLE INITIALLY DEFERRED</code>, as
- shown in the following example. Schemas generated by the ODB compiler
- meet this requirement automatically.</p>
+ database schema that defines foreign key constraints may need to
+ declare such constraints as <code>DEFERRABLE INITIALLY DEFERRED</code>,
+ as shown in the following example. By default, schemas generated by
+ the ODB compiler meet this requirement automatically.</p>
<pre class="sql">
CREATE TABLE Employee (
@@ -16925,6 +16932,12 @@ CREATE TABLE Employee (
DEFERRABLE INITIALLY DEFERRED);
</pre>
+ <p>You can override the default behavior and instruct the ODB
+ compiler to generate non-deferrable foreign keys by specifying
+ the <code>--fkeys-deferrable-mode not_deferrable</code> ODB
+ compiler option. Note, however, that in this case the order in
+ which you persist, update, and erase objects within a transaction
+ becomes important.</p>
<h3><a name="16.5.4">16.5.4 Constraint Violations</a></h3>
@@ -17646,14 +17659,14 @@ namespace odb
<h3><a name="17.5.2">17.5.2 Foreign Key Constraints</a></h3>
- <p>ODB relies on standard SQL behavior which requires that
+ <p>ODB assumes the standard SQL behavior which requires that
foreign key constraints checking is deferred until the
transaction is committed. Default PostgreSQL behavior is
to check such constraints immediately. As a result, when
used with ODB, a custom database schema that defines foreign
- key constraints must declare such constraints as
+ key constraints may need to declare such constraints as
<code>INITIALLY DEFERRED</code>, as shown in the following example.
- Schemas generated by the ODB compiler meet this requirement
+ By default, schemas generated by the ODB compiler meet this requirement
automatically.</p>
<pre class="sql">
@@ -17662,6 +17675,13 @@ CREATE TABLE Employee (
employer BIGINT REFERENCES Employer(id) INITIALLY DEFERRED);
</pre>
+ <p>You can override the default behavior and instruct the ODB
+ compiler to generate non-deferrable foreign keys by specifying
+ the <code>--fkeys-deferrable-mode not_deferrable</code> ODB
+ compiler option. Note, however, that in this case the order in
+ which you persist, update, and erase objects within a transaction
+ becomes important.</p>
+
<h3><a name="17.5.3">17.5.3 Unique Constraint Violations</a></h3>
<p>Due to the granularity of the PostgreSQL error codes, it is impossible
@@ -18533,14 +18553,14 @@ class long_class_name
<h3><a name="18.5.3">18.5.3 Foreign Key Constraints</a></h3>
- <p>ODB relies on standard SQL behavior which requires that
+ <p>ODB assumes the standard SQL behavior which requires that
foreign key constraints checking is deferred until the
transaction is committed. Default Oracle behavior is
to check such constraints immediately. As a result, when
used with ODB, a custom database schema that defines foreign
- key constraints must declare such constraints as
+ key constraints may need to declare such constraints as
<code>INITIALLY DEFERRED</code>, as shown in the following example.
- Schemas generated by the ODB compiler meet this requirement
+ By default, schemas generated by the ODB compiler meet this requirement
automatically.</p>
<pre class="sql">
@@ -18550,6 +18570,13 @@ CREATE TABLE Employee (
DEFERRABLE INITIALLY DEFERRED);
</pre>
+ <p>You can override the default behavior and instruct the ODB
+ compiler to generate non-deferrable foreign keys by specifying
+ the <code>--fkeys-deferrable-mode not_deferrable</code> ODB
+ compiler option. Note, however, that in this case the order in
+ which you persist, update, and erase objects within a transaction
+ becomes important.</p>
+
<h3><a name="18.5.4">18.5.4 Unique Constraint Violations</a></h3>
<p>Due to the granularity of the Oracle error codes, it is impossible
@@ -19667,12 +19694,19 @@ namespace odb
<h3><a name="19.5.2">19.5.2 Foreign Key Constraints</a></h3>
- <p>ODB relies on standard SQL behavior which requires that foreign
+ <p>ODB assumes the standard SQL behavior which requires that foreign
key constraints checking is deferred until the transaction is
committed. The only behavior supported by SQL Server is to check
- such constraints immediately. As a result, schemas generated by
- the ODB compiler for SQL Server have foreign key definitions
- commented out. They are retained only for documentation.</p>
+ such constraints immediately. As a result, by default, schemas
+ generated by the ODB compiler for SQL Server have foreign key
+ definitions commented out. They are retained only for documentation.</p>
+
+ <p>You can override the default behavior and instruct the ODB
+ compiler to generate non-deferrable foreign keys by specifying
+ the <code>--fkeys-deferrable-mode not_deferrable</code> ODB
+ compiler option. Note, however, that in this case the order in
+ which you persist, update, and erase objects within a transaction
+ becomes important.</p>
<h3><a name="19.5.3">19.5.3 Unique Constraint Violations</a></h3>