Object Model Design

Prev	Chapter 15. Kernel Documentation	Next

- - -<authorblurb> -

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

-</authorblurb> - -

Essentials

- - -

Data Model

- - -

+Object Model Design
Prev Chapter 15. Kernel Documentation Next
Object Model 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
Data Model
acs-metadata-create.sql
acs-objects-create.sql
-acs-relationships-create.sql
-
-
Tcl Files
- - -
Not yet linked.
-
- -
Requirements
- - -
Object Model +acs-relationships-create.sql
Tcl Files
Not yet linked.
Requirements
Object Model Requirements
Groups Requirements
Permissions -Requirements
-
- -
- -
Introduction
- - - -
Before OpenACS 4, software developers writing OpenACS applications or modules +Requirements

Prev	Chapter 15. Kernel Documentation	Next

Introduction

Before OpenACS 4, software developers writing OpenACS applications or modules would develop each data model separately. However, many applications built on OpenACS share certain characteristics or require certain common services. -Examples of such services include:

- -

User comments
Storage of user-defined or extensible sets of attributes
Access control
General auditing and bookkeeping (e.g. creation date, IP addresses, and +Examples of such services include:
- User comments
- Storage of user-defined or extensible sets of attributes
- Access control
- General auditing and bookkeeping (e.g. creation date, IP addresses, and so forth)
- Presentation tools (e.g. how to display a field in a form or on a -page)
- -
All of these services involve relating additional service-related +page)

All of these services involve relating additional service-related information to application data objects. Examples of application objects -include:

- -

forum messages
A user home page
A ticket in the ticket tracker

- -

In the past, developers had to use ad-hoc and inconsistent schemes to +include:

forum messages
A user home page
A ticket in the ticket tracker

In the past, developers had to use ad-hoc and inconsistent schemes to interface to various "general" services. OpenACS 4 defines a central data model that keeps track of the application objects that we wish to manage, and serves as a primary store of metadata. By metadata, we mean data stored on behalf of an application outside of the application's data model in order to enable certain central services. The OpenACS 4 Object Model (or object system) manages several different kinds of data and metadata to allow us to provide general -services to applications:

- -

Object Identification
- -
Every application object is given a unique identifier in the system. This +services to applications:
- Object Identification
  Every application object is given a unique identifier in the system. This identifier can be used to find all data related to a particular object. -
- Object Context and Access Control
  - -
  Every object is created in a particular security context, so the system +
- Object Context and Access Control
  Every object is created in a particular security context, so the system can provide centralized access control. -
- Object Types and Attributes
  - -
  Objects are instances of developer-defined object types. Object types +
- Object Types and Attributes
  Objects are instances of developer-defined object types. Object types allow developers to customize the data that is stored with each object. -
- Relation Types
  - -
  Relation types provide a general mechanism for mapping instances of one +
- Relation Types
  Relation types provide a general mechanism for mapping instances of one object type (e.g. users) to instances of another object type (e.g. groups). -
- -
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
- -

- -

History

- - - -

The motivation for most of the facilities in the OpenACS 4 Object Model can be +

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 permission system

History

The motivation for most of the facilities in the OpenACS 4 Object Model can be understood in the context of the 3.x code base and the kinds of programming -idioms that evolved there. These are listed and discussed below.

- -

Object Identification

- - -

Object identification is a central mechanism in OpenACS 4. Every application +idioms that evolved there. These are listed and discussed below.

Object Identification

Object identification is a central mechanism in OpenACS 4. Every application object in OpenACS 4 has a unique ID which is mapped to a row in a central table called acs_objects. Developers that wish to use OpenACS 4 services need only take a few simple steps to make sure that their application objects appear in this table. The fact that every object has a known unique identifier means that the core can deal with all objects in a generic way. In other words, we use object identifiers to enable centralized services in a -global and uniform manner.

- -

Implicit Object Identifiers in OpenACS 3.x

- -

The motivation for implementing general object identifiers comes from +global and uniform manner.

Implicit Object Identifiers in OpenACS 3.x

The motivation for implementing general object identifiers comes from several observations of data models in OpenACS 3.x. Many modules use a (user_id, group_id, scope) column-triple for the purpose of recording ownership information on objects, for access control. User/groups also uses (user_id, group_id) pairs in its user_group_map table as a way to identify data associated with a -single membership relation.

- -

Also, in OpenACS 3.x many utility modules exist that do nothing more than +single membership relation.

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 table that maps application "page" data (static or dynamic pages on the website) to one or more user comments on @@ -131,17 +58,11 @@ as the "(on_which_table + on_what_id)" method for identifying application data. In particular, general comments stores its map from pages to comments using a "(on_which_table + on_what_id)" key plus the ID -of the comment itself.

- -

All of these composite key constructions are implicit object identifiers - +of the comment itself.

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, making the construction of generic application-independent services unnecessarily -difficult.

- -

Object Identifiers in OpenACS 4

- -

The OpenACS 4 Object Model defines a single mechanism that applications use to +difficult.

Object Identifiers in OpenACS 4

The OpenACS 4 Object Model defines a single mechanism that applications use to attach unique identifiers to application data. This identifier is the primary key of the acs_objects table. This table forms the core of what we need to provide generic services like access control, general attribute @@ -152,40 +73,20 @@ make sure every object the system is to manage is associated with a row in acs_objects. More importantly, if they do this, new services like general comments can be created without requiring existing applications -to "hook into" them via new metadata.

- -

Note: Object identifiers are a good example of metadata +to "hook into" them via new metadata.

Note: Object identifiers are a good example of metadata in the new system. Each row in acs_objects stores information about the application object, but not the application object itself. This becomes more clear if you skip ahead and look at the SQL schema code -that defines this table.

- -

Object Context and Access Control

- - -

Until the implementation of the general permissions system, every OpenACS +that defines this table.

Object Context and Access 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:

- - -

...	`scope`	`user_id`	`group_id`	...
...	`user`	`123`		...
...	`group`		`456`	...
...	`public`			...

- -

The first row represents an entry in User 123's personal address book, +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:

...	`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.

- -

In this way, the scoping columns identify the security context in which a +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 -of people).

- -

In OpenACS 4, rather than breaking the world into a limited set of scopes, +of people).

In OpenACS 4, rather than breaking the world into a limited set of scopes, every object lives in a single context. A context is just an abstract name for the default security domain to which the object belongs. Each context has a unique identifier, and all the contexts in a system form a @@ -194,62 +95,38 @@ forum topic might list a subsite as its context. Thus, contexts make it easier to break the site up into security domains according to its natural structure. An object's context is stored in the context_id -column of the acs_objects table.

- -

We use an object's context to provide a default answer to questions +column of the acs_objects table.

We use an object's context to provide a default answer to questions regarding access control. Whenever we ask a question of the form "can user X perform action Y on object Z", the OpenACS security model will defer to an object's context if 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 +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 system and another for the +permission system and another for the party groups system. The context system -is also used to implement subsites.

- -

Object Types

- - -

As mentioned above, many OpenACS modules provide extensible data models, and +is also used to implement subsites.

Object Types

As mentioned above, many OpenACS modules provide extensible data models, and need to use application specific mechanisms to keep track of user defined attributes and to map application data to these attributes. In the past, modules either used user/groups or their own ad hoc data model to provide -this functionality.

- -

User/Groups in OpenACS 3.x

- -

The user/group system allowed developers to define group types +this functionality.

User/Groups in OpenACS 3.x

The user/group system allowed developers to define group types along with attributes to be stored with each instance of a group type. Each group type could define a helper table that stored attributes on each instance of the group type. This table was called the "_info" table because the name was generated by -appending _info to the name of the group type.

- -

The user/groups data model also provided the +appending _info to the name of the group type.

The user/groups data model also provided the user_group_type_member_fields and user_group_member_fields tables to define attributes for members of groups of a specific type and for members of a specific group, respectively. The user_group_member_field_map table stored values for both categories of attributes in its field_value column. These tables allowed developers and users to define custom sets of attributes to store on groups and group members without changing the data -model at the code level.

- -

Many applications in OpenACS 3.x and earlier used the group type mechanism in +model at the code level.

Many applications in OpenACS 3.x and earlier used the group type mechanism in ways that were only tangentially related to groups of users, just to obtain access to this group types mechanism. Thus the motivation for generalizing -the group types mechanism in OpenACS 4.

- -

Object Types and Subtypes

- -

In OpenACS 4 object types generalize the OpenACS 3.x notion of group +the group types mechanism in OpenACS 4.

Object Types and Subtypes

In OpenACS 4 object types generalize the OpenACS 3.x notion of group types. Each object type can define one or more attributes to be attached to instances of the type. This allows developers to define new types without -being artificially tied to a particular module (i.e. user/groups).

- -

In addition, the OpenACS 4 object model provides mechanism for defining +being artificially tied to a particular module (i.e. user/groups).

In addition, the OpenACS 4 object model provides mechanism for defining subtypes of existing types. A subtype of a parent type inherits all the attributes defined in the parent type, and can define some of its own. The motivation for subtypes comes from the need for OpenACS to be more @@ -259,50 +136,34 @@ containing a hodge podge of unrelated information that should have been normalized away. The canonical example of this is the explosion of the users table in OpenACS 3.x. In addition to being sloppy technically, -these fat tables have a couple of other problems:

- -

They degrade performance.
Denormalization can make it hard to maintain consistency constraints on -the data.

- -

Object subtypes provide a way to factor the data model while still keeping +these fat tables have a couple of other problems:

They degrade performance.
Denormalization can make it hard to maintain consistency constraints on +the data.

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.

- -

Object Attributes, Skinny Tables

- - -

As we described above, the OpenACS 3.x user/groups system stored object +information.

Object Attributes, Skinny Tables

As we described above, the OpenACS 3.x user/groups system stored object attributes in two ways. The first was to use columns in the helper table. The second consisted of two tables, one describing attributes and one storing values, to provide a flexible means for attaching attributes to metadata objects. This style of attribute storage is used in several other parts of OpenACS 3.x, and we will refer to it as "skinny tables". For -example:

- -

In the Ecommerce data model, the ec_custom_product_fields +example:
- In the Ecommerce data model, the ec_custom_product_fields table defines attributes for catalog products, and the ec_custom_product_field_values table stores values for those attributes.
- In the Photo DB data model, the ph_custom_photo_fields table defines attributes for the photographs owned by a specific user, and tables named according to the convention "ph_user_<user_id>_custom_info" are used to -store values for those attributes.
- -
In addition, there are some instances where we are not using this model +store values for those attributes.

In addition, there are some instances where we are not using this model but should, e.g. the users_preferences table, which stores preferences for registered users in columns such as prefer_text_only_p and dont_spam_me_p. The "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 Objet 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 @@ -313,13 +174,7 @@ 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 tables to model relationships +and more efficient, skinny tables are more flexible but limited.

Relation Types

Many OpenACS 3.x modules use mapping tables to model relationships between application objects. Again, the 3.x user/groups system provides the canonical example of this design style. In that system, there was a single table called user_group_map that kept track of which users @@ -328,53 +183,31 @@ user_group_member_fields_map tables to allow developers to attach custom attributes to group members. In fact, these 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.

- -

In OpenACS 4, relation types generalize this mechanism. Relation +particular group - a subtle but important distinction.

In OpenACS 4, relation types generalize this mechanism. Relation types allow developers to define general mappings from objects of a given type T, to other objects of a given type R. Each relation type is a subtype of acs_object, extended with extra attributes that store constraints on the relation, and the types of objects the relation actually maps. In turn, each instance of a relation type is an object that represents a single fact of the form "the object t of type T is related to the object r of type R." That is, each instance of a relation type is -essentially just a pair of objects.

- -

Relation types generalize mapping tables. For example, the 3.x user/groups +essentially just a pair of objects.

Relation types generalize mapping tables. For example, the 3.x user/groups data model can be largely duplicated using a single relation type describing the "group membership" relation. Group types would then be subtypes of this membership relation type. Group type attributes would be attached to the relation type itself. Group member attributes would be attached to instances of the membership relation. Finally, the mapping table would be -replaced by a central skinny table that the relation type system defines.

- -

Relation types should be used when you want to be able to attach data to +replaced by a central skinny table that the relation type system defines.

Relation types should be used when you want to be able to attach data to the "fact" that object X and object Y are related to each other. On the face of it, they seem like a redundant mechanism however, since one could easily create a mapping table to do the same thing. The advantage of registering this table as a relation type is that in principle the OpenACS 4 object system could use the meta data in the types table to do useful things in a generic way on all relation types. But this mechanism doesn't really -exist yet.

- -

Relation types are a somewhat abstract idea. To get a better feel for -them, you should just skip to the data model.

- -

Summary and Design Considerations

- - - -

The OpenACS 4 Object Model is designed to generalize and unify the following +exist yet.

Relation types are a somewhat abstract idea. To get a better feel for +them, you should just skip to the data model.

Summary and Design Considerations

The OpenACS 4 Object Model is designed to generalize and unify the following mechanisms that are repeatedly implemented in OpenACS-based systems to manage -generic and application specific metadata:

- -

Why not Object Databases?

- - -

The presence of a framework for subtyping and inheritance always brings up +generic and application specific metadata:

Why not Object Databases?

The presence of a framework for subtyping and inheritance always brings up the question of why we don't just use an object database. The main reason is that all of the major object database vendors ship products that are effectively tied to some set of object oriented programming languages. Their @@ -387,84 +220,46 @@ expressible in the host language. In particular, we lose many of the best features of the relational database model. This is a disaster from an ease of use standpoint. -

The "Object relational" systems provide an interesting +

The "Object relational" systems provide an interesting 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 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).

- -

Oracle

- - -

The conclusion: the best design is to add a limited notion of subtyping to +with this statement).

Oracle

The conclusion: the best design is to add a limited notion of subtyping to our existing relational data model. By doing this, we retain all the power of the relational data model while gaining the object oriented features we need -most.

- -

In the context of OpenACS 4, this means using the object model to make our +most.

In the context of OpenACS 4, this means using the object model to make our data models more flexible, so that new modules can 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 +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 -libraries might define.

- -

This last point cannot be over-stressed: the object model is not +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.

- -
Data Model
- - - -
Like most data models, the OpenACS Core data model has two levels:
- -
The knowledge level (i.e. the metadata model)
The operational level (i.e. the concrete data model)
- -
+meant to represent and store metadata, not application data.

Data Model

Like most data models, the OpenACS Core data model has two levels:

The knowledge level (i.e. the metadata model)
The operational level (i.e. the concrete data model)

You can browse the data models themselves from here: -

- -
+
acs-metadata-create.sql
acs-objects-create.sql
-acs-relationships-create.sql
- -
(Note that we have subdivided the operational level into the latter two -files.)
- -
The operational level depends on the knowledge level, so we discuss the +acs-relationships-create.sql
(Note that we have subdivided the operational level into the latter two +files.)
The operational level depends on the knowledge level, so we discuss the knowledge level first. In the text below, we include abbreviated versions of the SQL definitions of many tables. Generally, these match the actual definitions in the existing data model but they are meant to reflect design information, not implementation. Some less relevant columns may be left out, -and things like constraint names are not included.
- -
Knowledge-Level Model
- - -
The knowledge level data model for OpenACS objects centers around three tables +and things like constraint names are not included.
Knowledge-Level Model
The knowledge level data model for OpenACS objects centers around three tables that keep track of object types, attributes, and relation types. The first table is acs_object_types, shown here in an abbreviated -form:
+form:
- - -
- create table acs_object_types ( object_type varchar(1000) not null primary key, supertype references acs_object_types (object_type), @@ -478,13 +273,8 @@ ); -
- - -
This table contains one row for every object type in the system. The key -things to note about this table are:
- -
For every type, we store metadata for how to display this type in certain +
This table contains one row for every object type in the system. The key +things to note about this table are:
For every type, we store metadata for how to display this type in certain contexts (pretty_name and pretty_plural).
If the type is a subtype, then its parent type is stored in the column supertype.
We support a notion of "abstract" types that contain no instances (as of 9/2000 this is not actually used). These types exist only to @@ -493,19 +283,13 @@ create subtypes that represent real, concrete shapes like circles, squares, and so on.
Every type defines a table in which one can find one row for every instance of this type (table_name, id_column).
type_extension_table is for naming a table that stores extra -generic attributes.
- -
The second table we use to describe types is acs_attributes. +generic attributes.
The second table we use to describe types is acs_attributes. Each row in this table represents a single attribute on a specific object type (e.g. the "password" attribute of the "user" type). Again, here is an abbreviated version of what this table looks like. The actual table used in the implementation is somewhat different and is -discussed in a separate document.
+discussed in a separate document.
- - -
- create table acs_attributes ( attribute_id integer not null primary key object_type not null references acs_object_types (object_type), @@ -524,12 +308,7 @@ ); -
- - -
The following points are important about this table:
- -
Every attribute has a unique identifier.
Every attribute is associated with an object type.
We store various things about each attribute for presentation +
The following points are important about this table:
Every attribute has a unique identifier.
Every attribute is associated with an object type.
We store various things about each attribute for presentation (pretty_name, sort_order).
The data_type column stores type information on this attribute. This is not the SQL type of the attribute; it is just a human readable name for the type of data we think the attribute holds (e.g. @@ -547,26 +326,17 @@ encode information about the number of values an attribute may hold. Attributes can be defined to hold 0 or more total values.
The static_p flag indicates whether this attribute value is shard by all instances of a type, as with static member fields in C++. Static -attribute are like group level attributes in OpenACS 3.x.
- - -
The final part of the knowledge level model keeps track of relationship +attribute are like group level attributes in OpenACS 3.x.
The final part of the knowledge level model keeps track of relationship types. We said above that object relationships are used to generalize the 3.x notion of group member fields. These were fields that a developer could store on each member of a group, but which were contextualized to the membership relation. That is, they were really "attached" to the fact that a user was a member of a particular group, and not really attached to the user. This is a subtle but important distinction, because it allowed the 3.x system to store multiple sets of attributes on a given user, one set -for each group membership relation in which they participated.
+for each group membership relation in which they participated.
In OpenACS 4, this sort of data can be stored as a relationship type, in +acs_rel_types. The key parts of this table look like this:
-
In OpenACS 4, this sort of data can be stored as a relationship type, in -acs_rel_types. The key parts of this table look like this:
- - - -
- create table acs_rel_types ( rel_type varchar(1000) not null references acs_object_types(object_type), @@ -583,50 +353,28 @@ ); -
- - -
Things to note about this table:
- -
The main part of this table records the fact that the relation is between +
Things to note about this table:
The main part of this table records the fact that the relation is between instances of object_type_one and instances of object_type_two. Therefore, each instance of this relation type will be a pair of objects of the appropriate types.
The role columns store human readable names for the roles played by each object in the relation (e.g. "employee" and "employer"). Each role must appear in the acs_rel_roles.
The min_n_rels_one column, and its three friends allow the programmer to specify constraints on how many objects any given object can be -related to on either side of the relation.
- - -
This table is easier to understand if you also know how the acs_rels table works.
- -
To summarize, the acs_object_types and +related to on either side of the relation.

This table is easier to understand if you also know how the acs_rels table works.

To summarize, the acs_object_types and acs_attributes tables store metadata that describes every object type and attribute in the system. These tables generalize the group types data model in OpenACS 3.x. The acs_rel_types table stores -information about relation types.

- -
This part of the data model is somewhat analogous to the data dictionary +information about relation types.
This part of the data model is somewhat analogous to the data dictionary in Oracle. The information stored here is primarily metadata that describes the data stored in the operational level of the data -model, which is discussed next.
-

Relation Types

The relations system defines two packages: acs_rel_type for creating and managing relation types, and acs_rel for relating -objects.

- -

These two procedures just insert and remove roles from the +objects.

These two procedures just insert and remove roles from the acs_rel_roles table. This table stores the legal relationship "roles" that can be used when creating relation types. Examples of -roles are, say, "member", or "employer".

+roles are, say, "member", or "employer".

 
- 
-
--
  procedure create_role (
     role        in acs_rel_roles.role%TYPE
   );
@@ -1095,16 +697,9 @@
   );
 
 
-
+

The main functions in the acs_rel_type package are used to +create and drop relation types.

 
-
-The main functions in the acs_rel_type package are used to
-create and drop relation types.
-
- 
-
--
   procedure create_type (
     rel_type            in acs_rel_types.rel_type%TYPE,
     pretty_name         in acs_object_types.pretty_name%TYPE,
@@ -1133,16 +728,9 @@
   );
 
 
-
+

Finally, the acs_rel package provides an API that you use to +create and destroy instances of a relation type:

 
-
-Finally, the acs_rel package provides an API that you use to
-create and destroy instances of a relation type:
-
- 
-
--
   function new (
     rel_id              in acs_rels.rel_id%TYPE default null,
     rel_type            in acs_rels.rel_type%TYPE default 'relationship',
@@ -1158,19 +746,12 @@
   );
 
 
-
-
-
-A good example of how to use relation types appears in the OpenACS 4 data
+

A good example of how to use relation types appears in the OpenACS 4 data model for groups. As in 3.x, group membership is modeled using a mapping table, but now we create this mapping using relation types instead of explicitly creating a table. First, we create a helper table to store state -on each membership fact:

+on each membership fact:

 
- 
-
--
 create table membership_rels (
         rel_id          constraint membership_rel_rel_id_fk
                         references acs_rels (rel_id)
@@ -1183,15 +764,8 @@
 );
 
 
-
+

Then, we create a new object type to describe groups.

 
-
-Then, we create a new object type to describe groups.
-
- 
-
--
  acs_object_type.create_type (
    object_type => 'group',
    pretty_name => 'Group',
@@ -1203,24 +777,15 @@
  );
 
 
-
-
-
-In this example, we've made groups a subtype of
+

In this example, we've made groups a subtype of acs_object to make the code simpler. The actual data model is somewhat different. Also, we've assumed that there is a helper table called groups to store information on groups, and that there is a helper table called group_types that has been defined to store -extra attributes on groups.

- -

Now, assuming we have another object type called person to +extra attributes on groups.

Now, assuming we have another object type called person to represent objects that can be group members, we define the following -relationship type for group membership:

+relationship type for group membership:

 
- 
-
--
  acs_rel_type.create_role ('member');
 
  acs_rel_type.create_type (
@@ -1236,20 +801,13 @@
  );
 
 
-
-
-
-Now we can define the following procedure to add a new member to a group.
+

Now we can define the following procedure to add a new member to a group. All this function does is create a new instance of the membership relation type and then insert the membership state into the helper table that we define above. In the actual implementation, this function is implemented in the membership_rel package. Here we just define an independent -function:

+function:

 
- 
-
--
 function member_add (
     rel_id              in membership_rels.rel_id%TYPE default null,
     rel_type            in acs_rels.rel_type%TYPE default 'membership_rel',
@@ -1279,16 +837,9 @@
   end;
 
 
-
+

Another simple function can be defined to remove a member from a +group:

 
-
-Another simple function can be defined to remove a member from a
-group:
-
- 
-
--
   procedure member_delete (
     rel_id  in membership_rels.rel_id%TYPE
   )
@@ -1301,48 +852,11 @@
   end;
 
 
-
-
-

Document Revision #	Action Taken, Notes	When?	By Whom?
0.1	Creation	9/09/2000	Pete Su
0.2	Edited for ACS 4 Beta	9/30/2000	Kai Wu
0.3	Edited for ACS 4.0.1, fixed some mistakes, removed use of term -"OM"	11/07/2000	Pete Su

Document Revision #	Action Taken, Notes	When?	By Whom?
0.1	Creation	9/09/2000	Pete Su
0.2	Edited for ACS 4 Beta	9/30/2000	Kai Wu
0.3	Edited for ACS 4.0.1, fixed some mistakes, removed use of term +"OM"	11/07/2000	Pete Su

Prev	Home	Next
Object Model Requirements	Up	Permissions Requirements