Index: openacs-4/packages/acs-content-repository/www/doc/design.adp
===================================================================
RCS file: /usr/local/cvsroot/openacs-4/packages/acs-content-repository/www/doc/design.adp,v
diff -u -r1.2.2.3 -r1.2.2.4
--- openacs-4/packages/acs-content-repository/www/doc/design.adp 1 Dec 2015 11:17:39 -0000 1.2.2.3
+++ openacs-4/packages/acs-content-repository/www/doc/design.adp 1 Jul 2016 09:17:32 -0000 1.2.2.4
@@ -3,6 +3,9 @@
Content Repository Design
+
+ACS Documentation : Content Repository
+
I. Essentials
@@ -56,20 +59,21 @@
Object Model. As such the same design tradeoffs apply.
The content repository stores all revisions of all content items in a single table, rather than maintaining separate tables for -"live" and other revisions. The single-table approach dramatically -simplifies most operations on the repository, including adding -revisions, marking a "live" revision, and maintaining a full -version history. The drawback of this approach is that accessing -live content is less efficient. Given the ID of a content item, it -is not possible to directly access the live content associated with -that item. Instead, an extra join to the revisions table is -required. Depending on the production habits of the publisher, the -amount of live content in the repository may be eclipsed by large -numbers of infrequently accessed working drafts. The impact of this -arrangement is minimized by storing the actual content data in a -separate tablespace (preferably on a separate disk) from the actual -revisions table, reducing its size and allows the database server -to scan and read it more efficiently.
+"live" and other revisions. The single-table approach +dramatically simplifies most operations on the repository, +including adding revisions, marking a "live" revision, +and maintaining a full version history. The drawback of this +approach is that accessing live content is less efficient. Given +the ID of a content item, it is not possible to directly access the +live content associated with that item. Instead, an extra join to +the revisions table is required. Depending on the production habits +of the publisher, the amount of live content in the repository may +be eclipsed by large numbers of infrequently accessed working +drafts. The impact of this arrangement is minimized by storing the +actual content data in a separate tablespace (preferably on a +separate disk) from the actual revisions table, reducing its size +and allows the database server to scan and read it more +efficiently.The Object Model provides a
graphic overview of the the how the content repository is designed.
@@ -80,5 +84,5 @@
karlg\@arsdigita.com
-Last Modified: $Id: design.html,v 1.1.1.1 2001/03/13 22:59:26 ben
-Exp $
+Last Modified: $Id: design.html,v 1.1.1.1.30.1 2016/06/22 07:40:41
+gustafn Exp $