Some comments on the WC SQL schema (r33179:r33180):
> /* ### the following tables define the BASE tree */
>
> CREATE TABLE REPOSITORY (
> id INTEGER PRIMARY KEY AUTOINCREMENT,
>
> /* the UUID of the repository */
> uuid TEXT NOT NULL,
>
> /* URL of the root of the repository */
> url TEXT NOT NULL
> );
>
> CREATE INDEX I_UUID ON REPOSITORY (uuid);
>
>
> CREATE TABLE WORKING_COPY (
> id INTEGER PRIMARY KEY AUTOINCREMENT,
>
> /* foreign key to REPOSITORY.id */
> repos_id INTEGER NOT NULL,
>
> /* absolute path in the local filesystem */
> local_path TEXT NOT NULL,
>
Why NOT NULL? local_path is only needed when the metadata is stored outside
the wc.
> /* repository path corresponding to root of the working copy */
> repos_path TEXT NOT NULL
> );
>
> CREATE UNIQUE INDEX I_LOCAL_PATH ON WORKING_COPY (local_path);
>
>
> CREATE TABLE DIRECTORY (
> id INTEGER PRIMARY KEY AUTOINCREMENT,
>
> wc_id INTEGER NOT NULL,
>
> /* relative path from wcroot */
> local_relpath TEXT NOT NULL,
>
> /* path in repository */
> /* ### for switched subdirs, this could point to something other than
> ### local_relpath would imply. anything else for switching? */
> repos_path TEXT NOT NULL
For non-switched directories, repos_path can be derived from local_relpath.
And non-switched is the more common case. Storing repos_path always (it is
NOT NULL) seems slightly redundant.
(Also, what does switched mean here? Switched relative to the parent, or
relative to the wc root?)
> );
>
> CREATE UNIQUE INDEX I_DIR_PATH ON DIRECTORY (wc_id, local_relpath);
>
>
> CREATE TABLE NODE (
> id INTEGER PRIMARY KEY AUTOINCREMENT,
>
> dir_id INTEGER NOT NULL,
>
What is dir_id of the wc root dir?
> filename TEXT,
>
filename NOT NULL? The empty string can represent the "this dir" entry
(is there another reason NULL are allowed?).
> revnum INTEGER NOT NULL,
>
> kind INTEGER NOT NULL,
>
> text_id INTEGER,
>
> /* ### NOT NULL? do we always have this info? */
> changed_rev INTEGER,
> /* ### or use TEXT and ISO-8601 datetime? */
> changed_date INTEGER,
What is the precision of this INTEGER? Days? Seconds? Microseconds?
> changed_author TEXT,
>
> /* ### the following fields are used to define the WORKING tree */
> conflict_old TEXT,
> conflict_new TEXT,
> conflict_working TEXT,
> prop_reject TEXT, /* ### is this right? */
>
> /* ### note: these are caches from the server! */
> lock_token TEXT,
> lock_owner TEXT,
> lock_comment TEXT,
> lock_date INTEGER, /* ### or TEXT and ISO? */
>
Same question.
>
> /* ### some text or prop changes exist. this node is in a changelist. */
^ ^
One of these two sentences doesn't belong here?
> changelist_id INTEGER
> );
>
> CREATE UNIQUE INDEX I_PATH ON NODE (dir_id, filename);
> CREATE INDEX I_NODELIST ON NODE (dir_id);
> CREATE INDEX I_LOCKS ON NODE (lock_token);
>
>
> CREATE TABLE PROPERTIES (
> node_id INTEGER NOT NULL,
>
> name TEXT NOT NULL,
>
> value BLOB NOT NULL,
>
> PRIMARY KEY (node_id, name)
> );
>
> CREATE UNIQUE INDEX I_NODE_PROPS ON PROPERTIES (node_id);
>
>
> CREATE TABLE BASE_TEXT (
> id INTEGER PRIMARY KEY AUTOINCREMENT,
>
> checksum TEXT NOT NULL,
>
Checksum kind? (corresponds to the 'kind' field of svn_checksum_t)
> compression INTEGER NOT NULL,
>
> /* ### do we need to deal with repos-size vs. eol-style-size? this
> ### size should be what is in ACTUAL so we can quickly detect
> ### differences. */
s/should be what is/is what should be/ ?
> actual_size INTEGER NOT NULL,
>
> /* ### used to verify the pristine file is "proper" */
> stored_size INTEGER NOT NULL,
>
> refcount INTEGER NOT NULL
> );
>
> CREATE UNIQUE INDEX I_CHECKSUM ON BASE_TEXT (checksum);
>
> /* ------------------------------------------------------------------------- */
>
> /* ### the following tables define the WORKING tree */
>
> /* ### add/delete nodes */
> CREATE TABLE NODE_CHANGES (
> id INTEGER PRIMARY KEY AUTOINCREMENT,
>
> dir_id INTEGER NOT NULL,
>
> filename TEXT,
>
> /* ### NULL kind implies "deletion". or use a special enumerated value? */
> kind INTEGER,
>
> copyfrom_repos_path TEXT,
> copyfrom_revnum INTEGER,
>
> changelist_id INTEGER
> );
>
> CREATE UNIQUE INDEX I_PATH_CHANGES ON NODE_CHANGES (dir_id, filename);
> CREATE INDEX I_NODELIST_CHANGES ON NODE_CHANGES (dir_id);
>
>
> CREATE TABLE PROPERTIES_NEW (
> node_changes_id INTEGER NOT NULL,
>
> name TEXT NOT NULL,
>
> value BLOB NOT NULL,
>
> PRIMARY KEY (node_changes_id, name)
> );
>
> CREATE UNIQUE INDEX I_NEW_NODE_PROPS ON PROPERTIES_NEW (node_changes_id);
>
>
> CREATE TABLE PROPERTIES_EDIT (
> node_id INTEGER NOT NULL,
>
> name TEXT NOT NULL,
>
> /* ### NULL implies deletion. */
> value BLOB,
>
> PRIMARY KEY (node_id, name)
> );
>
> CREATE UNIQUE INDEX I_EDIT_NODE_PROPS ON PROPERTIES_EDIT (node_id);
>
Repeating what was discussed on IRC:
CREATE TABLE PROPERTIES_WORKING (
dir_id INTEGER NOT NULL,
/* ### scheduled-delete files don't have prop changes! */
filename TEXT NOT NULL,
/* propname */
name TEXT NOT NULL,
/* ### NULL implies deletion. */
value BLOB,
PRIMARY KEY (dir_id, filename, name)
);
CREATE UNIQUE INDEX I_WORKING_PROPS ON PROPERTIES_WORKING (dir_id, filename);
>
> CREATE TABLE CHANGELIST (
> id INTEGER PRIMARY KEY AUTOINCREMENT,
>
> wc_id INTEGER NOT NULL,
>
> name TEXT NOT NULL
> );
>
> CREATE UNIQUE INDEX I_CHANGELIST ON CHANGELIST (wc_id, name);
> CREATE UNIQUE INDEX I_CL_LIST ON CHANGELIST (wc_id);
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-09-19 14:42:36 CEST