| Prev | Chapter 15. Kernel Documentation | Next |
|---|
By Pete Su
-======= -By Pete Su
->>>>>>> 1.32 +A major goal in OpenACS 4 is to unify and normalize many of the core services @@ -90,11 +85,7 @@ 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 -<<<<<<< object-system-requirements.html -data model exist, which you can read about in ???.
Modifiable Data Models
Another recurring applications problem is how to store a modifiable data -======= 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 ->>>>>>> 1.32 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 @@ -135,13 +126,8 @@ that store metadata on application objects. The object type system supports subtyping with inheritance, so new object types can be defined in terms of existing object types.
The OM data model forms the main part of the OpenACS 4 Kernel data model. The -<<<<<<< object-system-requirements.html -other parts of the Kernel data model include:
Parties and Groups
Permissions
Each of these is documented elsewhere at length.
The data model for the object system provides support for the following -kinds of schema patterns that are used by many existing OpenACS modules:
Object identification is a central mechanism in the new metadata system. -======= other parts of the Kernel data model include:
Parties and Groups
Permissions
Each of these is documented elsewhere at length.
The data model for the object system provides support for the following kinds of schema patterns that are used by many existing OpenACS modules:
Object identification is a central mechanism in the new metadata system. ->>>>>>> 1.32 The fact that every object has a known unique identifier means that the core can deal with all objects in a generic way. Thus the only action required of an application to obtain any general service is to "hook into" the @@ -216,17 +202,10 @@ developers to represent a hierarchy of object contexts. These contexts are used as the basis for the permissions system. In general, if an object has no explicit permissions attached to it, then it inherits -<<<<<<< object-system-requirements.html -permissions from its context.
The context data model also forms the basis of the subsites system, and is -a basic part of the permissions system, -described in separate documents.
The context data model should provide the following facilities:
50.10 Unique ID
Every context should have a unique ID in the system.
50.20 Tree Structure
The data model should support a tree structured organization of contexts. -That is, contexts can be logically "contained" within other -======= permissions from its context.
The context data model also forms the basis of the subsites system, and is a basic part of the permissions system, described in separate documents.
The context data model should provide the following facilities:
50.10 Unique ID
Every context should have a unique ID in the system.
50.20 Tree Structure
The data model should support a tree structured organization of contexts. That is, contexts can be logically "contained" within other ->>>>>>> 1.32 contexts (i.e. contexts have parents) and contexts can contain other contexts (i.e. contexts can have children).
50.30 Data Model Constraints
All objects must have a context ID. This ID must refer to an existing context or be NULL. The meaning of a NULL context is determined by the @@ -285,4 +264,4 @@ 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 databases. | 08/29/2000 | Richard Li |
| 0.8 | Rewrote intro to match language and concepts in the design document. Also cleaned up usage a bit in the requirements section. Added short vague -requirements on relation types. | 09/06/2000 | Pete Su |
| 0.9 | Edited for ACS 4 Beta release. | 09/30/2000 | Kai Wu |