Index: openacs-4/packages/acs-core-docs/www/object-system-design.adp =================================================================== RCS file: /usr/local/cvsroot/openacs-4/packages/acs-core-docs/www/object-system-design.adp,v diff -u -r1.4 -r1.5 --- openacs-4/packages/acs-core-docs/www/object-system-design.adp 25 Apr 2018 08:38:28 -0000 1.4 +++ openacs-4/packages/acs-core-docs/www/object-system-design.adp 3 Sep 2024 15:37:32 -0000 1.5 @@ -1,7 +1,11 @@ -{/doc/acs-core-docs {ACS Core Documentation}} {Object Model Design} +{/doc/acs-core-docs/ {ACS Core Documentation}} {Object Model Design} Object Model Design +

Object Model -Design

<authorblurb>

By Pete Su, Michael Yoon, Richard Li, -Rafael Schloming

</authorblurb>
+Design
+

By Pete Su, Michael Yoon, Richard Li, Rafael Schloming

+OpenACS docs are written by the named authors, and may be edited by +OpenACS documentation staff.

Essentials

@@ -71,8 +77,8 @@

The next section will explore these facilities in the context of the particular programming idioms that we wish to generalize.

Related Links

This design document should be read along with the design -documents for the new groups system, subsites and the -permissions system +documents for the new groups system, subsites and the permission +system

@@ -138,8 +144,8 @@

Object Context and Access -Control

Until the implementation of the general permissions system, -every OpenACS application had to manage access control to its data +Control

Until the implementation of the general permission system, every +OpenACS application had to manage access control to its data separately. Later on, a notion of "scoping" was introduced into the core data model.

"Scope" is a term best explained by example. Consider some hypothetical rows in the address_book table:

@@ -177,7 +183,7 @@ there is no information about user X's permission to perform action Y on object Z.

The context system forms the basis for the rest of the OpenACS access control system, which is described in two separate -documents: one for the permissions +documents: one for the permission system and another for the party groups system. The context system is also used to implement subsites.

@@ -227,10 +233,9 @@ still keeping track of the fact that each member of a subtype (i.e. for each row in the subtype's table), is also a member of the parent type (i.e. there is a corresponding row in the parent type -table). Therefore, applications an use this mechanism without -worrying about this bookkeeping themselves, and we avoid having -applications pollute the core data model with their specific -information.

+table). Therefore, applications use this mechanism without worrying +about this bookkeeping themselves, and we avoid having applications +pollute the core data model with their specific information.

Object Attributes, Skinny @@ -258,20 +263,21 @@ users_preferences table (exactly the kind of data model change that has historically complicated the process of upgrading to a more recent OpenACS -version).

The Objet Model generalizes the scheme used in the old OpenACS -3.x user/groups system. It defines a table called acs_attributes that record what attributes -belong to which object types, and how the attributes are stored. As -before, attributes can either be stored in helper tables, or in a -single central skinny table. The developer makes this choice on a -case by case basis. For the most part, attribute data is stored in -helper tables so that they can take full advantage of relational -data modeling and because they will generally be more efficient. -Occasionally, a data model will use skinny tables because doing so -allows developers and users to dynamically update the set of -attributes stored on an object without updating the data model at -the code level. The bottom line: Helper tables are more functional -and more efficient, skinny tables are more flexible but -limited.

+version).

The ACS Object Model generalizes the scheme used in the old +OpenACS 3.x user/groups system. It defines a table called +acs_attributes that record what +attributes belong to which object types, and how the attributes are +stored. As before, attributes can either be stored in helper +tables, or in a single central skinny table. The developer makes +this choice on a case by case basis. For the most part, attribute +data is stored in helper tables so that they can take full +advantage of relational data modeling and because they will +generally be more efficient. Occasionally, a data model will use +skinny tables because doing so allows developers and users to +dynamically update the set of attributes stored on an object +without updating the data model at the code level. The bottom line: +Helper tables are more functional and more efficient, skinny tables +are more flexible but limited.

Relation Types

Many OpenACS 3.x modules use mapping @@ -343,13 +349,13 @@ existing SQL or SQL-like database engine. Examples of systems like this include the new Informix, PostgreSQL 7, and Oracle has something like this too. The main problem with these systems: each -one implements their own non-portable extensions to SQL to -implement subtyping. Thus, making OpenACS data models portable -would become even more difficult. In addition, each of these object -systems have strange limitations that make using inheritance -difficult in practice. Finally, object databases are not as widely -used as traditional relational systems. They have not been tested -as extensively and their scalability to very large databases is not +one implements their own nonportable extensions to SQL to implement +subtyping. Thus, making OpenACS data models portable would become +even more difficult. In addition, each of these object systems have +strange limitations that make using inheritance difficult in +practice. Finally, object databases are not as widely used as +traditional relational systems. They have not been tested as +extensively and their scalability to very large databases is not proven (though some will disagree with this statement).

@@ -361,11 +367,11 @@ easily gain access to generic features. However, while the API itself doesn't enforce the idea that applications only use the object model for metadata, it is also the case that the data model -is not designed to scale to large type hierarchies. In the more +is not designed to scale too large type hierarchies. In the more limited domain of the metadata model, this is acceptable since the type hierarchy is fairly small. But the object system data model is not designed to support, for example, a huge type tree like the -Java runtime libraries might define.

This last point cannot be over-stressed: the object model is not meant to be used for large +Java run time libraries might define.

This last point cannot be over-stressed: the object model is not meant to be used for large scale application data storage. It is meant to represent and store metadata, not application data.