<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" 'http://www.w3.org/TR/html4/loose.dtd"'>
<html><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8"><title>Object Model Requirements</title><link rel="stylesheet" href="openacs.css" type="text/css"><meta name="generator" content="DocBook XSL Stylesheets V1.60.1"><link rel="home" href="index.html" title="OpenACS Core Documentation"><link rel="up" href="kernel-doc.html" title="Chapter 14. Kernel Documentation"><link rel="previous" href="kernel-overview.html" title="Overview"><link rel="next" href="object-system-design.html" title="Object Model Design"></head><body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="navheader"><a href="http://openacs.org"><img src="/doc/images/alex.jpg" style="border:0" alt="Alex logo"></a><table width="100%" summary="Navigation header" border="0"><tr><td width="20%" align="left"><a accesskey="p" href="kernel-overview.html">Prev</a> </td><th width="60%" align="center">Chapter 14. Kernel Documentation</th><td width="20%" align="right"> <a accesskey="n" href="object-system-design.html">Next</a></td></tr></table><hr></div><div class="sect1" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="object-system-requirements"></a>Object Model Requirements</h2></div></div><div></div></div><div class="authorblurb"><p>By Pete Su</p>
          OpenACS docs are written by the named authors, and may be edited
          by OpenACS documentation staff.
        </div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="object-system-requirements-"></a>I. Introduction</h3></div></div><div></div></div><p>A major goal in OpenACS 4 is to unify and normalize many of the core services
of the system into a coherent common data model and API. In the past, these
services were provided to applications in an ad-hoc and irregular fashion.
Examples of such services include:</p><div class="itemizedlist"><ul type="disc"><li><p>General Comments</p></li><li><p>User/groups</p></li><li><p>Attribute storage in user/groups</p></li><li><p>General Permissions</p></li><li><p>Site wide search</p></li><li><p>General Auditing</p></li></ul></div><p>All of these services involve relating extra information and services to
application data objects, examples of which include:</p><div class="itemizedlist"><ul type="disc"><li><p>Bboard messages</p></li><li><p>A user home page</p></li><li><p>A ticket in the Ticket Tracker</p></li><li><p>A photograph in the PhotoDB</p></li></ul></div><p>In the past, developers had to use ad-hoc and inconsistent schemes to
interface to the various &quot;general&quot; services mentioned above. Since
each service used its own scheme for storing its metadata and mapping this
data to application objects, we could not implement any kind of centralized
management system or consistent administrative pages for all the services.
Consequently, a large amount of duplicate code appeared throughout the system
for dealing with these services.</p><p>Unifying and &quot;normalizing&quot; these interfaces, to minimize the
amount of code repetition in applications, is a primary goal of OpenACS 4. Thus
the Object Model (OM, also referred to later as the object system) is
concerned primarily with the storage and management of <span class="emphasis"><em>metadata</em></span>, on
any object within a given instance of OpenACS 4. The term &quot;metadata&quot;
refers to any extra data the OM stores on behalf of the application - outside
of the application's data model - in order to enable certain generic
services. The term &quot;object&quot; refers to any entity being represented
within the OpenACS, and typically corresponds to a single row within the
relational database.</p></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="object-system-requirements-vision"></a>Vision Statement</h3></div></div><div></div></div><p>The OpenACS 4 Object Model must address five high-level requirements that
repeatedly exhibit themselves in the context of existing services in OpenACS 3.x,
as described below.</p><p><span class="strong">Object Identifiers for General Services</span></p><p>Generic services require a single unambiguous way of identifying
application objects that they manage or manipulate. In OpenACS 3.x, there are
several different idioms that construct object identifiers from other data.
Many modules use a <tt class="computeroutput">(user_id, group_id, scope)</tt> triple combination
for the purpose of recording ownership information on objects for access
control. User/groups also uses <tt class="computeroutput">(user_id, group_id)</tt> pairs in its
<tt class="computeroutput">user_group_map</tt> table as a way to identify data associated with a
single membership relation.</p><p>Also in OpenACS 3.x, many utility modules exist that do nothing more than
attach some extra attributes to existing application data. For example,
general comments maintains a mapping table that maps application
&quot;page&quot; data (static or dynamic) to one or more user comments on the
page, by constructing a unique identifier for each page. This identifier is
usually a combination of the table in which the data is stored, and the value
of the primary key value for the particular page. This idiom is referred to
as the &quot;(on_which_table + on_what_id)&quot; method for identifying
application data. General comments stores its map from pages to comments
using a &quot;(on_which_table + on_what_id)&quot; key, plus the id of the
comment itself.</p><p>All of these composite key constructions are implicit object identifiers:
they build a unique ID out of other pieces of the data model. The problem is
that their definition and use is ad-hoc and inconsistent. This makes the
construction of generic application-independent services difficult.
Therefore, the OpenACS 4 Object Model should provide a centralized and uniform
mechanism for tagging application objects with unique identifiers.</p><p><span class="strong">Support for Unified Access Control</span></p><p>Access control should be as transparent as possible to the application
developer. Until the implementation of the general permissions system, every
OpenACS application had to manage access control to its data separately. Later
on, a notion of &quot;scoping&quot; was introduced into the core data
model.</p><p>&quot;Scope&quot; is a term best explained by example. Consider some
hypothetical rows in the <tt class="computeroutput">address_book</tt> table:</p><div class="informaltable"><table cellspacing="0" border="1"><colgroup><col><col><col><col></colgroup><tbody><tr><td><span class="strong">...</span></td><td><span class="strong"><tt class="computeroutput">scope</tt></span></td><td><span class="strong"><tt class="computeroutput">user_id</tt></span></td><td><span class="strong"><tt class="computeroutput">group_id</tt></span></td><td><span class="strong">...</span></td></tr><tr><td>...</td><td><tt class="computeroutput">user</tt></td><td><tt class="computeroutput">123</tt></td><td> </td><td>...</td></tr><tr><td>...</td><td><tt class="computeroutput">group</tt></td><td> </td><td><tt class="computeroutput">456</tt></td><td>...</td></tr><tr><td>...</td><td><tt class="computeroutput">public</tt></td><td> </td><td> </td><td>...</td></tr></tbody></table></div><p>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.</p><p>In this way, the scoping columns identify the security context in which a
given object belongs, where each context is <span class="emphasis"><em>either</em></span> a person
<span class="emphasis"><em>or</em></span> a group of people <span class="emphasis"><em>or</em></span> the general public (itself a group
of people).</p><p>The problem with this scheme is that we are limited to using only users
and groups as scopes for access control, limiting applications to a single
level of hierarchy. Worse, the scoping system demanded that every page
needing access to a given application had to do an explicit scope check to
make sure access was allowed - if a developer was careless on just one site
page, a security problem could result.</p><p>Thus the OpenACS 4 Object Model must support a more general access control
system that allows access control domains to be hierarchical, and specifiable
with a single piece of data, instead of the old composite keys described
above.</p><p><span class="strong">Extensible Data Models</span></p><p>Another problem with previous OpenACS data models is that many of the central
tables in the system became bloated as they were extended to support an
increasing number of modules. The <tt class="computeroutput">users</tt> 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
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,
would improve maintainability greatly. Furthermore, the ability to allow
applications or users to define new extensions to existing tables, and have
some central metadata facility for keeping track of what data belong to which
tables, would be very useful.</p><p>Thus the motivation for providing <span class="emphasis"><em>object types</em></span> and
<span class="emphasis"><em>subtyping</em></span> in the OpenACS 4 Object Model. The OM should allow developers
to define a hierarchy of metadata <span class="emphasis"><em>object types</em></span> with subtyping and
inheritance. Developers can then use the framework to allow users to define
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.</p><p><span class="strong">Design Note:</span> 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 <a href="object-system-design.html#object-system-design-summary">Summary and Design Considerations</a>.</p><p><span class="strong">Modifiable Data Models</span></p><p>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
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:</p><div class="itemizedlist"><ul type="disc"><li><p>User/groups: developers and users can attach custom data to group types,
groups, and members of groups.</p></li><li><p>In the Ecommerce data model, the <tt class="computeroutput">ec_custom_product_fields</tt>
table defines attributes for catalog products, and the
<tt class="computeroutput">ec_custom_product_field_values</tt> table stores values for those
attributes.</p></li><li><p>In the PhotoDB data model, the <tt class="computeroutput">ph_custom_photo_fields</tt> table
defines attributes for the photographs owned by a specific user, and tables
named according to the convention
&quot;<tt class="computeroutput">ph_user_&lt;user_id&gt;_custom_info</tt>&quot; are used to
store values for those attributes.</p></li></ul></div><p>Thus the Object Model must provide a general mechanism for applications
and developers to modify or extend data models, without requiring changes to
the SQL schema of the system. This ensures that all applications use the same
base schema, resulting in a uniform and more maintainable system.</p><p><span class="strong">Generic Relations</span></p><p>Many OpenACS applications define simple relationships between application
objects, and tag those relationships with extra data. In OpenACS 3.x, this was
done using <span class="emphasis"><em>mapping tables</em></span>. The user/groups module has the most
highly developed data model for this purpose, using a single table called
<tt class="computeroutput">user_group_map</tt> that mapped users to groups. In addition, it uses
the the <tt class="computeroutput">user_group_member_fields</tt> and
<tt class="computeroutput">user_group_member_fields_map</tt> tables to allow developers to
attach custom attributes to group members. In fact, these custom attributes
were not really attached to the users, but to the fact that a user was a
member of a particular group - a subtle but important distinction. As a
historical note, in OpenACS 3.x, user/groups was the only part of the system that
provided this kind of data model in a reusable way. Therefore, applications
that needed this capability often hooked into user/groups for no other reason
than to use this part of its data model.</p><p>The OpenACS 4 data model must support generic relations by allowing developers
to define a special kind of object type called a <span class="emphasis"><em>relation type</em></span>.
Relation types are themselves object types that do nothing but represent
relations. They can be used by applications that previously used user/groups
for the same purpose, but without the extraneous, artificial
dependencies.</p></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="object-system-requirements-system-overview"></a>System Overview</h3></div></div><div></div></div><p>The Object Model package is a combination of data model and a procedural
API for manipulating application objects within an OpenACS instance. The OM
allows developers to describe a hierarchical system of <span class="emphasis"><em>object types</em></span>
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.</p><p>The OM data model forms the main part of the OpenACS 4 Kernel data model. The
other parts of the Kernel data model include:</p><div class="itemizedlist"><ul type="disc"><li><p>Parties and Groups</p></li><li><p>Permissions</p></li></ul></div><p>Each of these is documented elsewhere at length.</p></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="object-system-requirements-use-cases"></a>Use-cases and User-scenarios</h3></div></div><div></div></div><p>(Pending as of 8/27/00)</p></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="object-system-requirements-links"></a>Related Links</h3></div></div><div></div></div><div class="itemizedlist"><ul type="disc"><li><p><a href="object-system-design.html">OpenACS 4 Object Model Design</a></p></li><li><p><a href="objects.html">OpenACS Data Models and the Object System</a></p></li></ul></div></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="object-system-requirements-data-model"></a>Requirements: Data Model</h3></div></div><div></div></div><p>The data model for the object system provides support for the following
kinds of schema patterns that are used by many existing OpenACS modules:</p><div class="variablelist"><dl><dt><span class="term"><span class="strong">10.0 Object Identification and Storage</span></span></dt><dd><p>Object identification is a central mechanism in the new metadata system.
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 &quot;hook into&quot; the
object system.</p><p>In OpenACS 3.x, modules use ad-hoc means to construct unique identifiers for
objects that they manage. Generally, these unique IDs are built from other
IDs that happen to be in the data model. Because there is no consistency in
these implementations, every application must hook into every service
separately.</p><p>Examples of utilities that do this in OpenACS 3.x system are:</p><div class="itemizedlist"><ul type="disc"><li><p>User/groups: Information is attached to group membership relations.</p></li><li><p>General Comments: Comments are attached to objects representing some kind
of document.</p></li><li><p>General Permissions: Stores access control information on application
data.</p></li><li><p>User Profiling: Maps users to pieces of content that they have looked at;
content identifiers must be managed in a uniform way.</p></li><li><p>Site Wide Search: Stores all content in a single flat table, with object
identifiers pointing to the object containing the content in the first place.
This way, we can search the contents of many different types of objects in a
uniform way.</p></li></ul></div><p>The OM will support and unify this programming idiom by providing objects
with unique identifiers (unique within a given OpenACS instance) and with
information about where the application data associated with the object is
stored. The identifier can be used to refer to collections of heterogeneous
application data. More importantly, object identifiers will enable developers
to readily build and use generic services that work globally across a
system.</p><p>The object identifiers should be subject to the following
requirements:</p><p><span class="strong">10.10 Uniqueness</span></p><p>The object ID should be unique among all the IDs in the entire OpenACS system
in which the object lives.</p><p><span class="strong">10.20 Useful as a Reference</span></p><p>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.</p><p><span class="strong">10.30 Storable</span></p><p>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.</p><p><span class="strong">10.40 Moveable</span></p><p>Objects should be mobile between databases. That is, information will
often need to be moved between multiple servers (development, staging, and
production), so a mechanism for moving this data is necessary. In addition, a
mechanism for tagging these objects in a way similar to CVS would be useful
in determining which objects need to be synchronized.</p></dd><dt><span class="term"><span class="strong">20.0 Object Types</span></span></dt><dd><p>An <span class="emphasis"><em>object type</em></span> refers to a specification of one or more
attributes to be managed along with a piece of application data.</p><p>The object system should provide a data model for describing and
representing object types. This data model is somewhat analogous to the
Oracle data dictionary, which stores information about all user defined
tables in the system.</p><p>The canonical example of this kind of data model occurs in the current OpenACS
3.x user/groups module, which allows the developer to create new <span class="emphasis"><em>group
types</em></span> that can contain not only generic system level attributes but also
extended, developer-defined attributes. In addition, these attributes can
either be attached to the group type itself, and shared by all instances, or
they can be different for each instance. At its core, the OpenACS 4 object system
is meant to be a generalization of this mechanism. The data model should
allow developers to at least do everything they used to with user/groups, but
without its administrative hassles.</p><p>Therefore, the data model must be able to represent object types that have
the following characteristics:</p><p><span class="strong">20.10 Type Name</span></p><p>A human readable name for the object type.</p><p><span class="strong">20.20 Type Attributes</span></p><p>Attributes whose values are shared by all instances of the object
type.</p><p><span class="strong">20.30 Object Attributes</span></p><p>Attributes that are specific to each particular object belonging to a
given type.</p><p>The data model must also enforce certain constraints on object types:</p><p><span class="strong">20.40 Type Uniqueness</span></p><p>Object type names must be unique.</p><p><span class="strong">20.50 Attribute Name Uniqueness</span></p><p>Attribute names must be unique in the scope of a single object type and
any of its parent types.</p></dd><dt><span class="term"><span class="strong">30.0 Type Extension</span></span></dt><dd><p>The Object Model must support the definition of object types that are
subtypes of existing types. A subtype inherits all the attributes of its
parent type, and defines some attributes of its own. A critical aspect of the
OM is parent types may be altered, and any such change must propagate to
child subtypes.</p><p>The OM data model must enforce constraints on subtypes that are similar to
the ones on general object types.</p><p><span class="strong">30.10 Subtype Uniqueness</span></p><p>Subtype names must be unique (this parallels requirement 10.40).</p><p><span class="strong">30.20 Subtype Attribute Name Uniqueness</span></p><p>Attribute names must be unique in the scope of a single object
subtype.</p><p><span class="strong">30.30 Parent Type Prerequisite</span></p><p>Subtypes must be defined in terms of parent types that, in fact, already
exist.</p><p><span class="strong">30.40</span></p><p>The extended attribute names in a subtype must not be the same as those in
its parent type.</p></dd><dt><span class="term"><span class="strong">35.0 Methods</span></span></dt><dd><p><span class="strong">35.10 Method and Type Association</span></p><p>The OM data model should define a mechanism for associating procedural
code, called <span class="emphasis"><em>methods</em></span>, with objects of a given type. Methods are
associated with the each object <span class="emphasis"><em>type</em></span> - not each object
<span class="emphasis"><em>instance</em></span>.</p><p><span class="strong">35.20 Method Sharing</span></p><p>All instances of a given object type should share the same set of defined
methods for that type.</p></dd><dt><span class="term"><span class="strong">40.0 Object Attribute Value Storage</span></span></dt><dd><p>In addition to information on types, the OM data model provides for the
centralized storage of object attribute values. This facility unifies the
many ad-hoc attribute/value tables that exist in various OpenACS 3.x data models,
such as:</p><div class="itemizedlist"><ul type="disc"><li><p>User groups: Each instance of a group type can have custom data.</p></li><li><p>Photo DB: Users can define their own custom metadata to attach to
photograph objects.</p></li><li><p>Ecommerce: Vendors can attach custom fields to the data model describing
their products.</p></li></ul></div><p><span class="strong">40.10 Generic Retrieval</span></p><p>Attributes should be stored so that they are retrievable in a way that is
independent of the type of the object that they belong to. That is, the only
data needed to retrieve an attribute should be the system-wide ID of an
object (see requirement 10.20 above) and the attribute name.</p><p><span class="strong">40.20 Inherited Attributes</span></p><p>The system should allow for the automatic retrieval of inherited attribute
values, for an object belonging to a subtype.</p><p><span class="strong">40.30. Constraints on Attributes</span></p><p>The system should allow the developer to put down constraints on the
values that an attribute may hold, for the purposes of maintaining
application specific integrity rules.</p></dd><dt><span class="term"><span class="strong">50.0 Object Contexts</span></span></dt><dd><p>In OpenACS 3.x, there was a notion of &quot;scope&quot; for application
objects. An object could be belong to one of three scopes: public, group or
user. This provided a crude way to associate objects with particular scopes
in the system, but it was awkward to use and limited in flexibility.</p><p>The OpenACS 4 Object Model provides a generalized notion of scope that allows
developers to represent a hierarchy of object <span class="emphasis"><em>contexts</em></span>. 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
permissions from its context.</p><p>The context data model also forms the basis of the <a href="">subsites system</a>, and is
a basic part of the <a href="permissions-requirements.html" title="Permissions Requirements">permissions system</a>,
described in separate documents.</p><p>The context data model should provide the following facilities:</p><p><span class="strong">50.10 Unique ID</span></p><p>Every context should have a unique ID in the system.</p><p><span class="strong">50.20 Tree Structure</span></p><p>The data model should support a tree structured organization of contexts.
That is, contexts can be logically &quot;contained&quot; within other
contexts (i.e. contexts have parents) and contexts can contain other contexts
(i.e. contexts can have children).</p><p><span class="strong">50.30 Data Model Constraints</span></p><p>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
implementation.</p><p><span class="strong">Note:</span></p><p>The current system interprets the NULL context as meaning the default
&quot;site-wide&quot; context in some sense. I wanted to note this fact for
others, but there is no need to make this a requirement of the system. I
think it would be reasonable to have a NULL context be an error (psu
8/24/2000).</p></dd><dt><span class="term"><span class="strong">55.0 Object Relations</span></span></dt><dd><p>The data model should include a notion of pair-wise relations between
objects. Relations should be able to record simple facts of the form
&quot;object X is related to object Y by relationship R,&quot; and also be
able to attach attributes to these facts.</p></dd></dl></div></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="object-system-requirements-api"></a>Requirements: API</h3></div></div><div></div></div><p>The API should let programmers accomplish the following actions:</p><div class="variablelist"><dl><dt><span class="term"><span class="strong">60.0 Object Type Creation</span></span></dt><dd><p><span class="strong">60.10 Create a New Object Type</span></p><p>The object system API should provide a procedure call that creates a new
object type by running the appropriate transactions on the object system data
model. This API call is subject to the constraints laid out in the data
model. We call this operation &quot;instantiating&quot; an object.</p><p><span class="strong">60.20 Create a New Object Subtype</span></p><p>The object system API should provide a procedure call for creating
subtypes of a given type. Operationally, this API is the same as requirement
60.10. Instances of subtypes automatically contain all attributes of the
parent type in addition to all attributes of the subtype. This API is subject
to the constraints laid out in the data model.</p><p><span class="strong">60.30 Create a New Relation Type</span></p><p>There should be an API call to create a new type of object relation.
Relation types can be modeled as object types. The API below for manipulating
attributes can then be used to add attributes to relation types.</p></dd><dt><span class="term"><span class="strong">70.0 Update an Object Type</span></span></dt><dd><p>The object system API must allow the programmer to modify, add, and delete
attributes from any object type. Updates should be propagated to any child
subtypes. This API is subject to the constraints laid out in the data
model.</p></dd><dt><span class="term"><span class="strong">80.0 Delete an Object Type</span></span></dt><dd><p>The system provides an API call for deleting an object type.</p><p><span class="strong">80.10</span></p><p>Deleting an object type destroys all instances of the type. It should be
an error to delete types that have dependent subtypes. This API is subject to
the constraints laid out in the data model.</p><p><span class="strong">80.10.10</span></p><p>However, the programmer should also be able to specify that all the
subtypes and instances of those subtypes be destroyed before destroying the
object type. This is similar to a &quot;delete cascade&quot; constraint in
SQL.</p></dd><dt><span class="term"><span class="strong">90.0 Object Instance Creation and Destruction</span></span></dt><dd><p>The system must provide API calls to manage the creation and destruction
of object instances.</p><p><span class="strong">90.10 Create an Instance of an Object Type</span></p><p>The system should provide an API call for creating a new instance of a
given object type. The new instance should be populated with values for each
of the attributes specified in the definition of the type. In addition, it
should be possible to create the new instance with an optional context ID
that refers to the default context that the object will live in.</p><p><span class="strong">90.20 Delete an Object Instance</span></p><p>The OM should provide an API call for object deletion. Objects can be
deleted only when no other objects in the system refer to them. Since it
might not be practical to provide a mechanism like &quot;delete cascade&quot;
here in a reliable way, providing such a facility in the system is
optional.</p></dd><dt><span class="term"><span class="strong">94.0 Object Relation Creation and Destruction</span></span></dt><dd><p>The system must provide API calls to manage the creation and destruction
of object relations.</p></dd><dt><span class="term"><span class="strong">94.10 Create an Object Relation</span></span></dt><dd><p>The OM must provide an API call to declare that two objects are related to
each other by a given relation type. This API call should also allow
programmers to attach attributes to this object relation.</p></dd><dt><span class="term"><span class="strong">94.20 Destroy an Object Relation</span></span></dt><dd><p>There should be an API call for destroying object relations and their
attributes.</p></dd><dt><span class="term"><span class="strong">95.10 Create and Destroy Contexts</span></span></dt><dd><p>The system should provide an API to create and destroy object
contexts.</p></dd><dt><span class="term"><span class="strong">100.10 Set Attribute Values for an Object</span></span></dt><dd><p>The system should provide an API for updating the attribute values of a
particular instance of an object type.</p></dd><dt><span class="term"><span class="strong">110.10 Get Attribute Values for an Object</span></span></dt><dd><p>The system should provide an API for retrieving attribute values from a
particular instance of an object type.</p></dd><dt><span class="term"><span class="strong">120.10 Efficiency</span></span></dt><dd><p>The Object Model must support the efficient storage and retrieval of
object attributes. Since the OM is intended to form the core of many general
services in the OpenACS, and these services will likely make extensive use of the
OM tables, queries on these tables must be fast. The major problem here seems
to be supporting subtyping and inheritance in a way that does not severely
impact query performance.</p></dd><dt><span class="term"><span class="strong">130.10 Ease of Use</span></span></dt><dd><p>Most OpenACS packages will be expected to use the Object Model in one way or
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 &quot;hook
into&quot; the object model, and that ability should not have a major impact
on the application data model.</p><p><span class="strong">Note:</span> Is the API the only way to obtain values? How does
this integrate with application level SQL queries?</p></dd></dl></div></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="object-system-requirements-history"></a>Revision History</h3></div></div><div></div></div><div class="informaltable"><table cellspacing="0" border="1"><colgroup><col><col><col><col></colgroup><tbody><tr><td><span class="strong">Document Revision #</span></td><td><span class="strong">Action Taken, Notes</span></td><td><span class="strong">When?</span></td><td><span class="strong">By Whom?</span></td></tr><tr><td>0.1</td><td>Creation</td><td>08/10/2000</td><td>Bryan Quinn</td></tr><tr><td>0.2</td><td>Major re-write</td><td>08/11/2000</td><td>Pete Su</td></tr><tr><td>0.3</td><td>Draft completed after initial reviews</td><td>08/22/2000</td><td>Pete Su</td></tr><tr><td>0.4</td><td>Edited, updated to conform to requirements template, pending freeze</td><td>08/23/2000</td><td>Kai Wu</td></tr><tr><td> </td><td>Final edits before freeze</td><td>08/24/2000</td><td>Pete Su</td></tr><tr><td>0.5</td><td>Edited for consistency</td><td>08/27/2000</td><td>Kai Wu</td></tr><tr><td>0.6</td><td>Put Object ID stuff first, because it makes more sense</td><td>08/28/2000</td><td>Pete Su</td></tr><tr><td>0.7</td><td>Added requirement that knowledge-level objects must be moveable between
databases.</td><td>08/29/2000</td><td>Richard Li</td></tr><tr><td>0.8</td><td>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.</td><td>09/06/2000</td><td>Pete Su</td></tr><tr><td>0.9</td><td>Edited for ACS 4 Beta release.</td><td>09/30/2000</td><td>Kai Wu</td></tr></tbody></table></div></div></div><div class="navfooter"><hr><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="kernel-overview.html">Prev</a> </td><td width="20%" align="center"><a accesskey="h" href="index.html">Home</a></td><td width="40%" align="right"> <a accesskey="n" href="object-system-design.html">Next</a></td></tr><tr><td width="40%" align="left">Overview </td><td width="20%" align="center"><a accesskey="u" href="kernel-doc.html">Up</a></td><td width="40%" align="right"> Object Model Design</td></tr></table><hr><address><a href="mailto:docs@openacs.org">docs@openacs.org</a></address></div><a name="comments"></a><center><a href="http://openacs.org/doc/current/object-system-requirements.html#comments">View comments on this page at openacs.org</a></center></body></html>