What is an Object Type?

Documentum is more than a document management system – it’s really an object management system. As an object-oriented repository,
Documentum is made up of different types of objects that work together to provide the functionality in the system.
For example, there is a user object that knows the Name, logon id, and email address for each user of the system.
There is a group object to help organize those users.
There’s a document object, a folder object, and a cabinet object (for obvious reasons).
There’s even an object that knows about all the different kinds of objects within a docbase

Documentum’s Type Hierarchy

Like any object-oriented system, Documentum’s object types are made up of objects with a more general purpose.
For example, dm_syobject is an object type that has a general purpose – it can be versioned, it can have content and
renditions, it has security, etc. A dm_script object is inherited from the dm_syobject, so it has all these qualities as well.
But a dm_script has a more specific use – its content contains a series of Documentum APIs, and when you double-click it in Workspace,
it executes those APIs.

Below is an inheritance diagram of some commonly used objects.

Figure 1:
Common Documentum Object Types

Custom Object Types

In order to configure Documentum to fit their particular business needs,
most people create several custom object types with attributes that they design themselves.
For example, imagine that you will use Documentum to manage the large number of resumes that are processed by your HR
department. A resume is obviously a type of document, but it has special attributes that describe it.
The applicant’s name, the position that he is applying for, and the date the resume was received are all attributes
that describe a resume that do not apply to a generic document. In this example, we would create a custom object type
named resume that is inherited from dm_document. We will create the resume with three attributes.

• Employee name Char (32)
• Position Char (32)
• Date Received Date/Time

However, since resume is a sub-type of dm_document, it will also contain all the attributes that dm_document contains,
such as object_name, title, subject, keywords and authors.

Creating an Object Type

To create a custom object type, you must use the DQL create type command. You must specify the name of the type,
the name of the type that you are inheriting from and the attributes that are specific to this type. For each attribute,
you must specify the data type of the attribute and if it is a repeating attribute. Valid datatypes are:

• DM_STRING: Stored in Oracle as a VARCHAR max size 255 (2000 if using Oracle)
• DM_INTERGER
• DM_BODLEAN
• DM_ID: Used to reference the r_object_id of another object. If an object is dumped and loaded into a new docbase, the referenced object will also be dumped and loaded

The syntax of the CREATE TYPE command follows:
CREATE TYPE type_name [(attribute_def {,attribute_def})] [WITH] SUPERTYPE parent_type

Determining the Attributes of an Existing Type

There are two ways to determine the attributes of an existing object type – with the describe DQL command and with the describe API.

Using DQL

The describe DQL command works the same way that it does in SQL. The syntax is:

describe object type

And the results look like this.
describe dm_document
Type Name: dm_document
SuperType Name: dm_sysobject
Attributes: 69
object_name CHAR(255)
r_object_type CHAR(32)
title CHAR(255)
subject CHAR(128)
authors CHAR(32) REPEATING
keywords CHAR(32) REPEATING
a_application_type CHAR(32)
a_status CHAR(16)
r_creation_date TIME
r_modify_date TIME
r_modifier CHAR(32)
r_access_date TIME
a_is_hidden BOOLEAN
i_is_deleted BOOLEAN
a_retention_date TIME
a_archive BOOLEAN
a_compound_architecture CHAR(16)
a_link_resolved BOOLEAN
i_reference_cnt INTEGER
i_has_folder BOOLEAN
i_folder_id ID REPEATING
r_composite_id ID REPEATING
r_composite_label CHAR(32) REPEATING
r_component_label CHAR(32) REPEATING
r_order_no INTEGER REPEATING
r_link_cnt INTEGER
r_link_high_cnt INTEGER
r_assembled_from_id ID
r_frzn_assembly_cnt INTEGER
r_has_frzn_assembly BOOLEAN
resolution_label CHAR(32)
r_is_virtual_doc INTEGER
i_contents_id ID
a_content_type CHAR(32)
r_page_cnt INTEGER
r_content_size INTEGER
a_full_text BOOLEAN
a_storage_type CHAR(32)
i_cabinet_id ID
owner_name CHAR(32)
owner_permit INTEGER
group_name CHAR(32)
group_permit INTEGER
world_permit INTEGER
i_antecedent_id ID
i_chronicle_id ID
i_latest_flag BOOLEAN
r_lock_owner CHAR(32)
r_lock_date TIME
r_lock_machine CHAR(32)
log_entry CHAR(80)
r_version_label CHAR(32) REPEATING
i_branch_cnt INTEGER
i_direct_dsc BOOLEAN
r_immutable_flag BOOLEAN
r_frozen_flag BOOLEAN
r_has_events BOOLEAN
acl_domain CHAR(32)
acl_name CHAR(32)
a_special_app CHAR(32)
i_is_reference BOOLEAN
r_creator_name CHAR(32)
r_is_public BOOLEAN
r_policy_id ID
r_resume_state INTEGER
r_current_state INTEGER
r_alias_set_id ID
i_is_replica BOOLEAN
i_vstamp INTEGER

Note:
Workspace will not let you issue a DESCRIBE command in the DQL Passthrough dialog. You can only issue the DESCRIBE command using the idql command line utility.

Using API

The describe api is very similar to the DESCRIBE DQL command. The syntax is

describe,c,type,object type

The result set is the same as the result of the DESCRIBE DQL command.

Tips and Tricks

Don’t Let Your Object Hierarchy Get Too Deep

For performance reasons, it is best to keep your object hierarchy as shallow as possible. The reason for this is that each level of the object hierarchy is stored in a separate table in the database. In order to manipulate an object, the Documentum server must join that object type’s tables with the tables of all of the other object types in the hierarchy above it. The more levels in your hierarchy, the more tables that must be joined together. And database joins are very expensive.

For example the following object hierarchy must do 4 joins (one for each level) when you query on plant_maintenance_report.
dm_document
|
|
Report
|
|
technical_report
|
|
plant_maintenance_report

It is advisable to try to collapse this hierarchy. The typical way to do this is to add all the custom attributes to the report object and add an extra attribute that identifies the type of report. You can still query for plant maintenance reports by using a where clause like this: where report_type = ‘Plant Maintenance Report’. The resulting type hierarchy will look like this.
dm_document
|
|
Report

Creating Text Attributes Longer than 255 Characters

Typically, the maximum size of a string attribute in Documentum is 255 characters. However, Oracle users know that the Oracle database can support columns up to 2000 characters long. Luckily, Documentum does allow users of Oracle to have attributes that are greater than 255 characters. To do this, you must first create the attribute with a length of 255 characters or less. Then you may issue the ALTER TYPE DQL command to increase the size.
CREATE TYPE large_string_test (large_string CHAR(255)) WITH SUPERTYPE dm_document
To increase the attribute’s size to 2000 characters, use the ALTER TYPE command.
ALTER TYPE LARGE large_string_test MODIFY large_string CHAR(2000)

Object Types as an Alternative to Registered Tables

Sometimes you may need a database table to store validation or auditing information, but you do not want to go through the hassle of registering a table. Documentum allows you to create object types with no supertype. Since these objects are not inherited from any other type, Documentum does not have to issue any joins or carry any unwanted baggage. The performance of querying a type with no supertype is similar to querying a registered table. The syntax of creating an object with no supertype is the same as creating a normal object – you simply specify “NULL” as the supertype.

Note that since this type of object is not inherited from dm_syobject, it can not live in a folder, it does not have content or ACLs and can not be versioned.

As an example of using an object with null supertype, imagine that you have an attribute dialog you wish to provide a picklist of values for the keywords attribute. You must issue a validation object with no supertype. The validation object has two attributes, constraint and data.
CREATE TYPE validation (constraint char(32), data char(32) WITH SUPERTYPE NULL
You then create several validation objects with different values for the keywords pick list.
CREATE validation OBJECT SET constraint = 'industry', SET data = 'Education'}
CREATE validation OBJECT SET constraint = 'industry', SET data = 'Petrochemical'}
CREATE validation OBJECT SET constraint = 'industry', SET data = 'Financial'}
Now to populate the pick list, issue a query like this
SELECT data FROM validation WHERE constraint = 'industry'