diff options
Diffstat (limited to 'doc/manual.xhtml')
-rw-r--r-- | doc/manual.xhtml | 70 |
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& 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> |