Documentum Object Types

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.

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'