Changes between Version 11 and Version 12 of SERVER_DATABASE_PERSISTENCE

Timestamp:

02/21/10 09:53:26 (15 years ago)

Author:

meddle

Comment:

--

SERVER_DATABASE_PERSISTENCE

@@ -90 +90 @@
      * The path is the last part of the key, for example title, page-size, background, color, etc...
      * Something like all the possible keys in the DB model.
+    * T_KEY_VALUE_CHANGES
+     * It has five colums, unique DB id (autoincrement), foreign key to the db id of T_RESOURCES, foreign key to the DB id of T_KEYS and two foreign ids to T_REVISIONS, SET_REVISION_ID and CHANGE_REVISION_ID
+     * It represents a key value of a resource (the key and resource foreign id) at revision (SET_REVISION_ID).
+     * The CHANGE_REVISION_ID is the id of the next revision (null if the SET_REVISION_ID is the current revision of the key of the resource)
+     * The two revision ids represent history links. The idea is when changin a key, to find its current value row (CHANGE_REVISION_ID is null there for that key of that resource),
+to modify the CHANGE_REVISION_ID to be the DB id of the new revision and to add a new row in the table for the same key and resource but with SET_REVISION_ID the DB id of the current revision and CHANGE_REVISION_ID - null.
+     * This way we can track history in the DB easely, get a value of a key of a resource at random revision, find previous revision, etc...
+     * The writes of a revision can be get from here (all the records that the DB id of the revision is SET_REVISION_ID). That helps the skip algorithm.
+    * T_KEY_VALUES
+     * Has two colums, a foreign key to the DB id of T_KEY_VALUE_CHANGES and a Clob column for persisted as string or binary data Immutables.
+     * This table contains the values for T_KEY_VALUE_CHANGES.
+    * T_REVISION_READS
+     * Has two colums, a foreign key to the DB id of T_REVISIONS and a VARCHAR column.
+     * This table represents the readed keys of a revision
+     * The varchar columns represent a full path of key (for example childre:Book.book.s2:children:Page A:title)
+     * The table can be represented as the T_KEY_VALUE_CHANGES table, but here we don't need links for the history, don't care of actual values, the meaning of the reads is simpler, so the structure of the table is simple.
+     * Reads are added rarely compared to writes, so the table is perfect for its purpose.
    * Schema diagram: TODO!!!
   === JDBC Template ===