X-Git-Url: http://git.kpe.io/?a=blobdiff_plain;f=doc%2Fref-ooddl.xml;h=4a2cffa140b4600703290805f4e6352301b5af1d;hb=bd6843e2084ce45d3d7b769e383c3cac589b5e93;hp=be98f6dc148bc7bbfebe7fb5a6b09c4c97500ebc;hpb=ef1af699cee8a79486bb3db7f75193bc32121f44;p=clsql.git diff --git a/doc/ref-ooddl.xml b/doc/ref-ooddl.xml index be98f6d..4a2cffa 100644 --- a/doc/ref-ooddl.xml +++ b/doc/ref-ooddl.xml @@ -589,12 +589,16 @@ - :normalisedp - specifies whether - this class uses normalised inheritance from parent classes. - Defaults to nil, i.e. non-normalised schemas. When true, + :normalizedp - specifies whether + this class uses normalized inheritance from parent classes. + Defaults to nil, i.e. non-normalized schemas. When true, SQL database tables that map to this class and parent classes are joined on their primary keys to get the full - set of database columns for this class. + set of database columns for this class. This means that + the primary key of the base class will be copied to all + subclasses as we insert so that all parent classes of an + instance will have the same value in their primary key slots + (see tests/ds-nodes.lisp and oodml.lisp) @@ -616,15 +620,16 @@ this class. - Normalised inheritance schemas + + Normalized inheritance schemas - Specifying that :normalisedp is T - tells &clsql; to normalise the database schema for inheritance. + Specifying that :normalizedp is T + tells &clsql; to normalize the database schema for inheritance. What this means is shown in the examples below. - With :normalisedp equal to NIL + With :normalizedp equal to NIL (the default) the class inheritance would result in the following: @@ -654,7 +659,7 @@ SQL table USER: - Using :normalisedp T, both + Using :normalizedp T, both view-classes need a primary key to join them on: @@ -676,7 +681,7 @@ SQL table NODE: ((user-id :accessor user-id :initarg :user-id :type integer :db-kind :key :db-constraints (:not-null)) (nick :accessor nick :initarg :nick :type (varchar 64))) - (:normalisedp t)) + (:normalizedp t)) SQL table USER: +---------+-------------+------+-----+---------+-------+ @@ -690,7 +695,7 @@ SQL table USER: In this second case, all slots of the view-class 'node are also available in view-class 'user, and can be used - as one would expect. For example, with the above normalised + as one would expect. For example, with the above normalized view-classes 'node and 'user, and SQL tracing turned on: @@ -716,7 +721,26 @@ CLSQL> (title test-user) CLSQL> (nick test-user) "test-user" + + Notes from a refactor of this code. + + There are many assumptions that need to be met for normalized classes to work + + * The each of the classes should have its own single key column (of a different name) + that will contain an identical value. EG: node has a node-id, setting which + is a node has a node-id and a setting-id which must be equal. You cannot use + node-id as the primary key on both tables (as I would have expected). The exception + to this seems to be if your class has no slots at all, then you dont need to have a + single key column, because your class is fully represented in the db by its parent(s) + * more than one parent class per normalized class should be considered experimental + and untested (vaya con Dios) + + * There are a few code paths that just dont pay any attention to normalized classes + eg: delete-records-for-instance + + + Examples