The OpenACS 4 Object Model must address five high-level requirements that @@ -52,7 +52,7 @@ model.
"Scope" is a term best explained by example. Consider some
hypothetical rows in the address_book table:
| ... | scope | user_id | group_id | ... |
| ... | user | 123 | ... | |
| ... | group | 456 | ... | |
| ... | public | ... |
The first row represents an entry in User 123's personal address book, the second row represents an entry in User Group 456's shared address -book, and the third row represents an entry in the site's public address +book, and the third row represents an entry in the site's public address book.
In this way, the scoping columns identify the security context in which a
given object belongs, where each context is either a person
or a group of people or the general public (itself a group
@@ -68,7 +68,7 @@
tables in the system became bloated as they were extended to support an
increasing number of modules. The users table is the best case
in point: it became full of columns that exist for various special
-applications (e.g. user portraits), but that aren't really related to
+applications (e.g. user portraits), but that aren't really related to
each other in any way except that they store information on users, i.e. the
table became grossly denormalized. Normalizing (breaking-down) this table
into several pieces, each of which is specific to a particular application,
@@ -82,13 +82,13 @@
custom extensions to the existing data models, and the OM does the
bookkeeping necessary to make this easier, providing a generic API for object
creation that automatically keeps track of the location and relationships
-between data.
Design Note: While this doesn't really belong in a +between data.
Design Note: While this doesn't really belong in a requirements document, the fact that we are constrained to using relational databases means that certain constraints on the overall design of the object data model exist, which you can read about in Summary and Design Considerations.
Modifiable Data Models
Another recurring applications problem is how to store a modifiable data model, or how to store information that may change extensively between releases or in different client installations. Furthermore, we want to avoid -changes to an application's database queries in the face of any custom +changes to an application's database queries in the face of any custom extensions, since such changes are difficult or dangerous to make at runtime, and can make updating the system difficult. Some example applications in OpenACS 3.x with modifiable data models include:
User/groups: developers and users can attach custom data to group types, @@ -150,7 +150,7 @@ system.
The object identifiers should be subject to the following requirements:
10.10 Uniqueness
The object ID should be unique among all the IDs in the entire OpenACS system in which the object lives.
10.20 Useful as a Reference
Applications should be able to use the unique object ID as a reference, -with which they can fetch any or all of the object's attributes.
10.30 Storable
Object IDs should be storable in tables. e.g. you should be able to use +with which they can fetch any or all of the object's attributes.
10.30 Storable
Object IDs should be storable in tables. e.g. you should be able to use them to implement mapping tables between objects, to represent relationships.
10.40 Moveable
Objects should be mobile between databases. That is, information will often need to be moved between multiple servers (development, staging, and @@ -258,7 +258,7 @@ another. Since it is important that the largest audience of developers possible adopts and uses the OM, it must be easy to incorporate into applications, and it must not impose undue requirements on an -application's data model. In other words, it should be easy to "hook +application's data model. In other words, it should be easy to "hook into" the object model, and that ability should not have a major impact on the application data model.
Note: Is the API the only way to obtain values? How does this integrate with application level SQL queries?
| Document Revision # | Action Taken, Notes | When? | By Whom? |
| 0.1 | Creation | 08/10/2000 | Bryan Quinn |
| 0.2 | Major re-write | 08/11/2000 | Pete Su |
| 0.3 | Draft completed after initial reviews | 08/22/2000 | Pete Su |
| 0.4 | Edited, updated to conform to requirements template, pending freeze | 08/23/2000 | Kai Wu |
| Final edits before freeze | 08/24/2000 | Pete Su | |
| 0.5 | Edited for consistency | 08/27/2000 | Kai Wu |
| 0.6 | Put Object ID stuff first, because it makes more sense | 08/28/2000 | Pete Su |
| 0.7 | Added requirement that knowledge-level objects must be moveable between |