</listitem>
<listitem>
<para>
- <parameter>:normalisedp</parameter> - specifies whether
- this class uses normalised inheritance from parent classes.
- Defaults to nil, i.e. non-normalised schemas. When true,
+ <parameter>:normalizedp</parameter> - 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)
</para>
</listitem>
</itemizedlist>
this class.
</para>
- <title>Normalised inheritance schemas</title>
+ <refsect2>
+ <title>Normalized inheritance schemas</title>
<para>
- Specifying that <symbol>:normalisedp</symbol> is <symbol>T</symbol>
- tells &clsql; to normalise the database schema for inheritance.
+ Specifying that <symbol>:normalizedp</symbol> is <symbol>T</symbol>
+ tells &clsql; to normalize the database schema for inheritance.
What this means is shown in the examples below.
</para>
<para>
- With <symbol>:normalisedp</symbol> equal to <symbol>NIL</symbol>
+ With <symbol>:normalizedp</symbol> equal to <symbol>NIL</symbol>
(the default) the class inheritance would result in the following:
</para>
<screen>
</screen>
<para>
- Using <symbol>:normalisedp</symbol> <symbol>T</symbol>, both
+ Using <symbol>:normalizedp</symbol> <symbol>T</symbol>, both
view-classes need a primary key to join them on:
</para>
<screen>
((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:
+---------+-------------+------+-----+---------+-------+
<para>
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:
</para>
<screen>
CLSQL> (nick test-user)
"test-user"
</screen>
+ <para>
+ 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
+
+ </para>
+ </refsect2>
</refsect1>
<refsect1>
<title>Examples</title>