Login | Register
My pages Projects Community openCollabNet

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Catacomb] reason for dasl_resource and version_resource as separate tables?

Hi Chris,
When we implemented Catacomb-v, we also consider the design choices of
keeping dasl_resource and version_resouce in one table and keeping them in
separate tables. Finally, we decided to put them in separate tables for 3

First, we wanted to minimize the impact on the Catacomb source code
caused by the change of the table structure of 'dasl_resource'. If we make
'dasl_resource' and 'version_resource' the same table, say
'dasl_resource', the primary key of 'dasl_resource' will be changed,
because one more column 'version' will join the primary key and the
'serialno' column can not be 'auto_increment' type any more. This will
cause a lot of changes to the Catacomb source code and every SQL statement
related to 'dasl_resource' table should be changed.

Second, 'dasl_resource' and 'version_resource' tables have different
meaning. 'dasl_resource' stores the current information and content of a
resource, and 'version_resource' contains the change history of a
resource. The 'textcontent' field in the 'version_resource' table could
only contain the delta (difference) between two versions of a resource, if
we apply 'diff' algorithm in Catacomb in future, which differs from the
'textcontent' field in 'dasl_resource' table.

Third,it is the performance reason. We assume that most resources are not
under version control in a Catacomb server. So, we keep the
'dasl_resource' table small and make the primary key more efficient by
separating 'dals_resource' and 'version_resource' tables. In this way, the
searching operation (dasl) and other operation (COPY, MOVE, PROPFIND,
etc.) will be faster.


On Mon, 31 Mar 2003, Chris Knight wrote:

> I've been working on the latest Catacomb code and I have a question. Why
> are there the dasl_resource and version_resource as separate tables? The
> columns are almost identical with the exception of the version column
> (and the isversioned column). A simple solution would be to use the same
> table and assume that a null version would be for non-versioned
> resources and would greatly reduce the number of "if versioned, alter
> version_resource, otherwise alter dasl_resource" code. Same goes for
> version_property.
> I'm likely overlooking something obvious. ;^)
> Also, I would like to replace the getetag column with something that is
> generated on the fly (based on serialno, version, and perhaps a third
> integer column that would be incremented upon each replacement/update.)
> _______________________________________________
> Catacomb mailing list
> Catacomb@webdav.org
> http://mailman.webdav.org/mailman/listinfo/catacomb