From a4f25daf17392c9c4b90de60b9d777290706f667 Mon Sep 17 00:00:00 2001 From: Boris Kolpackov Date: Mon, 8 Apr 2013 11:13:51 +0200 Subject: Generate add/drop foreign key migration statements Also add the --fkeys-deferrable-mode option. General schemas generation rework. --- doc/manual.xhtml | 70 +++++++++++++++++++++++++++++++++++++++++--------------- 1 file changed, 52 insertions(+), 18 deletions(-) (limited to 'doc') 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.

+ result, by default, schemas generated by the ODB compiler for + MySQL have foreign key definitions commented out. They are + retained only for documentation.

+ +

You can override the default behavior and instruct the ODB + compiler to generate non-deferrable foreign keys by specifying + the --fkeys-deferrable-mode not_deferrable ODB + compiler option. Note, however, that in this case the order in + which you persist, update, and erase objects within a transaction + becomes important.

15.6 MySQL Index Definitions

@@ -16909,14 +16916,14 @@ odb::database& db = ... } -

Finally, ODB relies on standard SQL behavior which requires +

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 DEFERRABLE INITIALLY DEFERRED, as - shown in the following example. Schemas generated by the ODB compiler - meet this requirement automatically.

+ database schema that defines foreign key constraints may need to + declare such constraints as DEFERRABLE INITIALLY DEFERRED, + as shown in the following example. By default, schemas generated by + the ODB compiler meet this requirement automatically.

 CREATE TABLE Employee (
@@ -16925,6 +16932,12 @@ CREATE TABLE Employee (
            DEFERRABLE INITIALLY DEFERRED);
+

You can override the default behavior and instruct the ODB + compiler to generate non-deferrable foreign keys by specifying + the --fkeys-deferrable-mode not_deferrable ODB + compiler option. Note, however, that in this case the order in + which you persist, update, and erase objects within a transaction + becomes important.

16.5.4 Constraint Violations

@@ -17646,14 +17659,14 @@ namespace odb

17.5.2 Foreign Key Constraints

-

ODB relies on standard SQL behavior which requires that +

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 INITIALLY DEFERRED, 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.

@@ -17662,6 +17675,13 @@ CREATE TABLE Employee (
   employer BIGINT REFERENCES Employer(id) INITIALLY DEFERRED);
+

You can override the default behavior and instruct the ODB + compiler to generate non-deferrable foreign keys by specifying + the --fkeys-deferrable-mode not_deferrable ODB + compiler option. Note, however, that in this case the order in + which you persist, update, and erase objects within a transaction + becomes important.

+

17.5.3 Unique Constraint Violations

Due to the granularity of the PostgreSQL error codes, it is impossible @@ -18533,14 +18553,14 @@ class long_class_name

18.5.3 Foreign Key Constraints

-

ODB relies on standard SQL behavior which requires that +

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 INITIALLY DEFERRED, 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.

@@ -18550,6 +18570,13 @@ CREATE TABLE Employee (
            DEFERRABLE INITIALLY DEFERRED);
+

You can override the default behavior and instruct the ODB + compiler to generate non-deferrable foreign keys by specifying + the --fkeys-deferrable-mode not_deferrable ODB + compiler option. Note, however, that in this case the order in + which you persist, update, and erase objects within a transaction + becomes important.

+

18.5.4 Unique Constraint Violations

Due to the granularity of the Oracle error codes, it is impossible @@ -19667,12 +19694,19 @@ namespace odb

19.5.2 Foreign Key Constraints

-

ODB relies on standard SQL behavior which requires that foreign +

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.

+ 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.

+ +

You can override the default behavior and instruct the ODB + compiler to generate non-deferrable foreign keys by specifying + the --fkeys-deferrable-mode not_deferrable ODB + compiler option. Note, however, that in this case the order in + which you persist, update, and erase objects within a transaction + becomes important.

19.5.3 Unique Constraint Violations

-- cgit v1.1