Object subtypes provide a way to factor the data model while 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 +corresponding row in the parent type 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.
As we described above, the OpenACS 3.x user/groups system stored object
@@ -163,7 +163,7 @@
"standard" way for an OpenACS 3.x-based application to add to the list
of user preferences is to add a column to the 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 Object Model generalizes the scheme used in the old OpenACS 3.x user/groups +complicated the process of upgrading to a more recent OpenACS 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
@@ -224,7 +224,7 @@
alternative. Here, some notion of subtyping is embedded into an 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
+problem with these systems: each 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
@@ -241,7 +241,7 @@
that the data model 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
+designed to support, for example, a huge type tree like the 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.