Objects and Types in Documentum 6.5 Content Management Foundations- A Sequel

Content persistence

We have seen so far how metadata is persisted but it is not obvious how content is persisted and associated with its metadata. All sysobjects (objects of type dm_sysobject and its subtypes) other than folders (objects of type dm_folder and its subtypes) can have associated content. We saw that a document can have content in the form of renditions as well as in primary format. How are these content files associated with a sysobject? In other words, how does Content Server know what metadata is associated with a content fi le? How does it know that one content fi le is a rendition of another one? Content Server manages content files using content objects, which (indirectly) point to the physical locations of content files and associate them with sysobjects.

Locating content files

Recall that Documentum repositories can store content in various types of storage systems including a file system, a Relational Database Management System (RDBMS), a content-addressed storage (CAS), or external storage devices. Content Server decides to store each file in a location based on the configuration and the presence of products like Content Storage Services. In general, users are not concerned about where the file is stored since Content Server is able to retrieve the file from the location where it was stored. We will discuss the physical location of a content file without worrying about why Content Server chose to use that location.

Content object

Every content file in the repository has an associated content object, which stores information about the location of the fi le and identifi es the sysobjects associated with it. These sysobjects are referred to as the parent objects of the content object.

A content object is an object of type dmr_content, whose key attributes are listed as follows:




Number of parent objects


List of object IDs of the parent objects


Object ID of the store object representing the storage area holding the content.


A value used internally to retrieve the content. The value and its usage depend upon the type of storage used.


When the content is stored in turbo storage, this property contains the actual content. If the content is larger than the size of this property (2000 characters for databases other than Sybase, 255 for Sybase), the content is stored in a dmi_subcontent object and this property is unused.

If the content is stored in content addressed storage, it contains the content address.

If the content is stored in external storage, it contains the token used to retrieve the content.


Identifies if it's a rendition and its related behavior

0 means original content

1 means rendition generated by server

2 means rendition generated by client

3 means rendition not to be removed when its primary content

is updated or removed


Object ID of the format object representing the format of the content


Content file size in bytes, except when the content is stored in external storage

Object-content relationship

Content Server manages content objects while performing content-related operations. Content associated with a sysobject is categorized as primary content or a rendition. A rendition is a content fi le associated with a sysobject that is not its primary content.

Content in the first content file added to a sysobject is called its primary content and its format is referred to as the primary format for the parent object. Any other content added to the parent object in the same format is also called primary content, though it is rarely done by users manually. This ability to add multiple primary content files is typically utilized programmatically by applications for their internal use.

While a sysobject can have multiple primary content files it is also possible for one content object to have multiple parent objects. This just means that a content file can be shared by multiple objects.

Putting it together

The details about content persistence can become confusing due to the number of objects involved and the relationships among various attributes. It becomes even more complicated when the full Content Server capabilities (such as multiple content files for one sysobject) are manifested. We will look at a simple scenario to visually grasp how content persistence works in common situations.

Documentum provides multiple options for locating the content file. DFC provides the getPath() method and DQL provides get_file_url administration method for this purpose. This section has been included to satisfy the reader's curiosity about content persistence and works through the information manually. This discussion can be treated as supplementary to technical fundamentals..

The sysobject is named paystub.jpg. The primary content file is in jpg format and the rendition is in pdf format, as shown in the following figure:

The following figure shows the objects involved in the content persistence for this document. The central object is of type dm_document. The figure also includes two content objects and one format object. Let's try to understand the relationships by asking specific questions.

How many content files, primary or renditions, are there for the document paystub.jpg? This question can be answered by looking for the corresponding content objects. We look for dmr_content objects that have the document's object ID in one of their parent_id values. This figure shows that there are two such content objects.

Which of these content objects represents the primary content and which one is a rendition? This can be determined by looking at the rendition attribute. The content object on the left shows rendition=0, which indicates primary content. The content object on the right shows rendition=2, which indicates rendition generated by client (recall that we manually imported this rendition).

What is the primary format for this document? This is easy to answer by looking at the a_content_type attribute on the document itself. If we need to know the format for a content object we can look for the dm_format object which has the same object ID as the value present in the format property of the content object. In the fi gure above, the format object for the primary content object is shown which represents a JPEG image. Thus, the format determined for the primary content of the object is expected to match the value of a_content_type property of the object. The format object for the rendition is not shown but it would be PDF.

What is the exact physical location of the primary content file? As mentioned in the beginning of this section, there are DFC and DQL methods which can provide this information. For understanding content persistence, we will deduce this manually for a file store, which represents storage on a file system. For other types of storage, an exact location might not be evident since we need to rely on the storage interface to access the content file. Deducing the exact file path requires the ability to convert a decimal number to a hexadecimal (hex) number; this can be done with pen and paper or using one of the free tools available on the Web. Also remember that negative numbers are represented with what is known as a 2's-complement notation and many of these tools either don't handle 2's complement or don't support enough digits for our purposes.

There are two parts of the file path—the root path for the file store and the path of the file relative to this root path. In order to fi gure out the root path, we identify the fi le store first. Find the dm_filestore object whose object ID is the same as the value in storage_id property of the content object. Then find the dm_location object whose object name is the same as the root property on the file store object. The file_ system_path property on this location object has the root path for the fi le store, which is C:\Documentum\data\localdev\content_storage_01 in the figure above.

In order to find the relative path of the content fi le, we look at data_ticket (data type integer) on the content object. Find the 8-digit hex representation for this number. Treat the hex number as a string and split the string with path separators (slashes, / or \ depending on the operating system) after every two characters. Suffi x the right-most two characters with the file extension (.jpg), which can be inferred from the format associated with the content object. Prefix the path with an 8-digit hex representation of the repository ID. This gives us the relative path of the content file, which is 00000010\80\00\09\be.jpg in the figure above. Prefix this path with the file store root path identified earlier to get the full path of the content file.

Content persistence in Documentum appears to be complicated at first sight. There are a number of separate objects involved here and that is somewhat similar to having several tables in a relational database when we normalize the schema. At a high level, this complexity in the content persistence model serves to provide scalability, flexibility by supporting multiple kinds of content stores, and ease of managing changes in such an environment.

Lightweight and shareable object types

So far we have primarily dealt with standard types. Lightweight and shareable object types work together to provide performance improvements, which are significant when a large number of lightweight objects share information. The key performance benefits are in terms of savings in storage and in the time it takes to import a large number of documents that share metadata. These types are suitable for use in transactional and archival applications but are not recommended for traditional content management.

The term transactional content (as in business transactions) was coined by Forrester Research to describe content typically originating from external parties, such as customers and partners, and driving transactional back-office business processes. Transactional Content Management (TCM) unifi es process, content, and compliance to support solutions involving transactional content. Our example scenario of mortgage loan approval process management is a perfect example of TCM. It involves numerous types of documents, several external parties, and sub-processes implementing parts of the overall process. Lightweight and shareable types play a central role in the High Volume Server, which enhances the performance of Content Server for TCM.

A lightweight object type (also known as LwSO for Lightweight SysObject ) is a subtype of a shareable type. When a lightweight object is created, it references an object of its shareable supertype called the parent object of the lightweight object. Conversely, the lightweight object is called the child object of the shareable object. Additional lightweight objects of the same type can share the same parent object. These lightweight objects share the information present in the common parent object rather than each carrying a copy of that information.

In order to make the best use of lightweight objects we need to address a couple of questions. When should we use lightweight objects? Lightweight objects are useful when there are a large number of attribute values that are identical for a group of objects. This redundant information can be pushed into one parent object and shared by the lightweight objects.

What kind of information is suitable for sharing in the parent object? System-managed metadata, such as policies for security, retention, storage, and so on, are usually applied to a group of objects based on certain criteria. For example, all the documents in one loan application packet could use a single ACL and retention information, which could be placed into the shareable parent object. The specific information about each document would reside in a separate lightweight object.

Lightweight object persistence

Persistence for lightweight objects works much the same way it works for objects of standard types, with one exception. A lightweight object is a subtype of a shareable type and these types have their separate tables as usual. For a standard type, each object has separate records in all of these tables, with each record identified by the object ID of the object. However, when multiple lightweight objects share one parent object there is only one object ID (of the parent object) in the tables of the shareable type. The lightweight objects need to refer to the object ID of the parent object, which is different from the object ID of any of the lightweight objects, in order to access the shared properties. This reference is made via an attribute named i_sharing_parent, as shown in the last figure.

Materialization of lightweight objects

A group of lightweight objects sharing a parent object can be considered to be tethered to the parent object. They are forced to share the parent object's properties with the other lightweight objects and are said to be unmaterialized in this state. Suppose that one (or several) of the lightweight objects needs to change some of the shared properties while others need to retain the existing values. In this scenario, it is not possible to just change the property on the parent object. The lightweight object needs to break away from the rest and also needs to take a private copy of the properties of the parent object so that it can have different values for these properties.

When a lightweight object gets its own private copy of the parent object, it is said to be materialized. This terminology is similar to that used by RDBMS systems where materialized views may result in copies of previously shared column values. The private copy of the parent object uses the object ID of the materialized lightweight object. This state is similar to the standard type persistence, except that the join continues to use i_sharing_parent on the lightweight object table.

Materialization also results in a behavior change related to deletion. Deleting an unmaterialized lightweight object leaves the parent object alone, even if it was the last lightweight object pointing to the parent object. Deleting a materialized lightweight object always deletes its private copy of the parent object.

A lightweight object type definition includes specification of the materialization behavior, with the following options:

  • Auto materialization—materialize automatically when certain operations occur
  • Materialization on request—only materialize when explicitly requested
  • Disallow materialization—do not materialize


Aspects extend behavior and attributes for objects. An object type defines the properties and behavior of all objects of that type (and of its subtypes, via inheritance). In contrast, aspects enable us to attach additional behavior and attributes to an object, regardless of its type. Using aspects can speed up development and improve code reuse because they offer the possibility of extending attributes and behavior without altering the underlying type defi nitions.

In our example scenario, suppose that the mortgage lending company has a training program and they want to enhance it by providing examples of real-life situations and how their organization handles them. For this purpose, they want to tag documents that serve as good examples for handling specific scenarios. Irrespective of the type of document, they want to be able to add the following attributes to an example document:




A single-valued string describing the example in a few words


A repeating string where each value describes a reason why this is an example.

In this scenario, we could create an aspect named Exemplary with these two attributes. We don't need to modify any of the existing types nor do we have to create any new standard types. These attributes can be attached to any document and only to the documents that need it.


Even though aspects can be attached regardless of the type of object, aspects cannot be attached to arbitrary types of objects. Aspects can be attached under the following restrictions on types:

  • An aspect can be attached to any sysobject
  • An aspect can be attached to any object of null type (type with no supertype),once the type has been altered to allow aspects

It is also possible to attach multiple aspects to one object but one aspect cannot be attached multiple times to the same object.

If an aspect's name contains a dot, such as jumbo.loan, it cannot have any properties. Why would we want an aspect without any properties? An aspect without any properties can serve as a fl ag where the presence of this fl ag can be checked on objects.

Default aspects

Even though aspects are not automatically tied to object types sometimes we may have a need to do just that (often for convenience). For example, we may have an existing type called dq_loan_doc and we may want all of its objects (and of its subtypes) to have an aspect dq_web_viewable attached. If an aspect is associated with an object type, the aspect is automatically attached to each new object of the specifi ed object type. Such an aspect is called a default aspect for the specifi ed type. Of course, this aspect can still be attached to objects of other types (subject to the restrictions mentioned earlier). Default aspects for an object type are recorded in dmi_type_info.default_aspects for the type.

What is the benefit of having a default aspect? If we need an aspect on every object of a type then making it a default aspect saves the effort of manually or programmatically attaching the aspect to each object. Why wouldn't we just alter the type to add those attributes to the type defi nition? Maybe the type is not allowed to be altered. Maybe it really needs to be an aspect and it is applicable to objects of other types as well.

Multiple default aspects can be associated with one object type. An object type inherits all the default aspects defined for its supertypes. When we add a default aspect to a type, the newly added aspect is only associated with new instances created after the addition of the default aspect. Existing instances of the type or its subtypes are not affected. Similarly, removal of a default aspect does not affect the existing instances of the type.

Content Server creates and manages an internal object type for each aspect. The names and definitions of aspect properties are stored in this internal type. The internal type is named dmi_type_id, where type_id is the object ID of the internal type.

Aspects provide an alternative to placing attributes on a standard object type. However, this option should be exercised carefully as a large number of aspects or ill-designed aspects can make usage and maintenance difficult. Remember that aspects are most useful when they are not needed on all the objects of a type but may be needed on objects of types that are unrelated via an inheritance hierarchy.

Querying objects

Document Query Language (DQL ) is a query language for Documentum just as Structured Query Language (SQL) is a query language for databases. In fact, DQL is a superset of ANSI SQL, which means that a well-formed query in ANSI SQL is also a well-formed DQL query. However, successful execution of a well-formed query depends on various factors such as existence of tables and availability of functions used in the query. DQL queries can be executed using IDQL (Interactive DQL shell ), Documentum Administrator, Webtop, or programmatically through DFC applications. The results returned by a query are collectively referred to as a result set. When executing a query programmatically, the result set is represented by a collection object, which is a non-persistent object.

DFC provides a rich set of functionality for interacting with objects, including creating, querying, and modifying objects. DFC is a programmatic means of interacting with objects and is used in applications. DQL is used both for scripting and with DFC in applications.

In this section, we will examine the SELECT, UPDATE, and DELETE DQL queries used for manipulating objects. However, this is just a small overview of DQL capabilities and the DQL Reference Documentation should be used to explore the full set of DQL capabilities.

SELECT query

A DQL query can be used to inspect or affect one or more objects in a repository. The most common type of DQL query is the SELECT query, which retrieves the properties of one or more objects. For example, consider the following query:

SELECT r_object_id, r_creation_date
FROM dm_document
WHERE object_name = 'LoanApp_1234567890.txt'

This query shows three keywords—SELECT, FROM, and WHERE. These keywords divide up the query into three parts:

  • SELECT clause (selected values list): The selected values list specifi es the properties to be retrieved.
  • FROM clause: The FROM clause specifies the object types to be queried.
  • WHERE clause: The WHERE clause is optional and specifies the conditions for matching the objects whose properties will be returned by the query. When the WHERE clause is present, the query is also called a conditional query.

A DQL query can also directly query database tables, though the tables need to be registered first. A registered table is a table from the underlying database that has been registered with the repository. This registration allows the table to be specified in a DQL query, either by itself or in conjunction with a type. A registered table can be used in place of an object type in most DQL queries and its columns can be used as properties in a DQL query.

Now, let's try to understand the semantics of this query. The FROM clause specifies that we want to consider objects of type dm_document. All the subtypes of dm_document are also included in the scope of this query. Among these objects, we only want to look at current versions of objects that have 'LoanApp_1234567890.txt' in their object_name property. The query will return the object ID (r_object_id property) and creation date (r_creation_date property) for all the resulting objects. Selection of non-current versions is discussed later.

No matter how (DFC or DQL) objects are queried, Content Server always enforces the configured security. Content Server will not return all documents just because a query requests all documents. It will only return the documents that the currently authenticated user is allowed to retrieve. Of course, the results can be further narrowed by conditions and arguments that are part of the query.

The same rules apply to the operations other than querying.



The comma-separated list after SELECT identifies the values to be returned. These values typically come from object properties, though they may include constants and calculations on properties as well. The allowed properties depend on the types specified in the FROM clause. For example:

SELECT object_name, title
FROM dm_document

Here the selected values are the properties object_name and title for the type dm_document. It is possible to rename the values being returned using the following syntax:

SELECT object_name AS Name, title AS Title
FROM dm_document

This capability is more useful and desirable when multiple types are present in the FROM clause:

SELECT d.r_object_id AS ObjectId, f.r_object_id AS FolderId
FROM dm_document d, dm_folder f

Note that the selected attributes are both r_object_id, so renaming enables us to distinguish between them. Also note that we need to associate the property name with the type name in this case and it is done by using the prefixes d. and f., where d and f are aliases for the types in the FROM clause. It is a good practice to use aliases for types and prefi x them to property names when multiple types are present in the FROM clause.

When one or more repeating attributes are included in the selected attributes, the results may be returned in two ways. If r_object_id is included in the selected attributes, the values of each repeating attribute are returned as one string containing comma-separated values. In this case, one row is returned per matching object. The following query and its result illustrate this behavior. There are two values in r_version_label and three in keywords but they are all returned in one row per object:

SELECT r_object_id, object_name, r_version_label, keywords
FROM dm_document
WHERE object_name = 'LoanApp_1234567891.txt








Application, 1234567891,Loan

If r_object_id is not present in the selected attributes, only one value per row is returned even for repeating attributes. This means that multiple rows may be returned for one object. The following query and its result illustrate this behavior. There are two values in r_version_label and three in keywords. As a result, only one value per row but multiple rows per object are returned:

SELECT object_name, i_position, r_version_label, keywords
FROM dm_document
WHERE object_name = 'LoanApp_1234567891.txt'
ORDER BY i_position DESC

















Note the use of ORDER BY clause and i_position attribute for sorting the results. DESC indicates descending order. Multiple comma-separated attributes can be specified in the ORDER BY clause for sorting.

It is possible to use an asterisk (*) instead of a list of attribute names to be returned. In general, the * returns a set of predefi ned attributes but the exact behavior depends on the queried types and the presence of certain hints in the query. For full details about the behavior of *, see the DQL Reference Manual.

A DQL query only works on the current versions of objects unless (ALL) is used after the type name. For example, the following query retrieves name and title for all versions:

SELECT object_name, title
FROM dm_document (ALL)

It is rare to run a select query without a WHERE clause because it doesn't filter objects of the specified type(s). A query without a WHERE clause may take an inordinately long time to return the results. The WHERE clause provides conditions or search criteria for narrowing down the search scope to find relevant objects.

WHERE clause

The WHERE clause specifies a condition, which may consist of multiple conditions that an object must satisfy to be a part of the result set. An object participates in the conditions via its properties. Functions, expressions, logical operations, and literals are used along with the properties to define the condition. The following examples illustrate the usage of the WHERE clause.

The following example shows the use of a string literal in the WHERE clause. Note that a string literal is placed within single quotes:

SELECT r_object_id, title, subject
FROM dm_document
WHERE object_name = 'LoanApp_1234567890.txt'

The following example shows that a numeric value does not use quotes. This query retrieves objects that have been updated at least once:

SELECT object_name
FROM dm_document
WHERE i_vstamp > 0

An object ID literal is placed within single-quotes. The following query retrieves one specific object from the repository using its object ID:

SELECT object_name
FROM dm_document
WHERE r_object_id = '0900001080002514'

A repeating property in a WHERE clause is used with the keyword ANY, as shown in the next example. This query retrieves all current documents that have any of the keywords set to application:

SELECT object_name
FROM dm_document
WHERE ANY keywords = 'application'

Another commonly used condition relates to dates and the DATE function is useful for such situations. The following query retrieves objects that have not been modified since 09/09/2009:

SELECT object_name
FROM dm_document
WHERE r_modify_date < DATE('09/09/2009')

In addition to a comparison with exact values, pattern matching can be performed against string attributes. The character % represents zero or more characters while _ represents exactly one character. Pattern matching is performed using LIKE and NOT LIKE predicates as shown in the following example.

SELECT r_object_id, title, subject
FROM dm_document
WHERE object_name LIKE 'LoanApp%'

This query matches all current documents whose names start with LoanApp. The use of NOT LIKE would match all current objects that LIKE would not have matched.

Pattern matching is great but how would we find names containing %rate, for example? Since % has a special meaning for the LIKE predicate, it needs to be escaped. Essentially, we need to distinguish the literal % from the pattern matching %. The following query illustrates how to escape a pattern-matching character.

SELECT r_object_id, title, subject
FROM dm_document
WHERE object_name LIKE '%\%rate%' ESCAPE '\'

Next we look at UPDATE queries, which are used for modifying objects.

UPDATE query

An UPDATE query updates one or more objects and has the following syntax:

UPDATE <type_name> OBJECT
WHERE <condition>

The WHERE clause works just as in the SELECT query. As before, the WHERE clause is optional but it is highly recommended that the WHERE clause not be omitted as far as possible because omitting it would lead to all objects of the type being updated (that are not otherwise restricted because of lack of permissions, immutability, or being checked out by another user).

<type_name> is the type or an ancestor type of the object(s) to be updated. An ancestor can be the parent or an ancestor's parent in a tree. Therefore, an ancestor type could be the supertype, supertype's supertype, and so on. Sometimes, the ancestor type is loosely referred to as supertype to include all these possibilities.

<property_updates> specify the property names and the corresponding values to be set.

The following example illustrates these concepts:

UPDATE dm_document OBJECT
SET title = 'John''s Loan Application',
SET subject = '1234567890'
WHERE r_object_id = '0900001080002514'

This query shows several new features. Note that the keyword OBJECT (OBJECTS is also acceptable) is required, since we are trying to update the objects. If OBJECT is omitted, the query will attempt to modify a registered table. <property_updates> usually takes the form SET <property_name> = <value>. If multiple properties are being updated, each SET clause is separated using a comma.

Also note that for title we used two apostrophes where we needed one in the value. It is true for all DQL queries that an apostrophe inside a string literal should be replaced with two to escape the special meaning of the apostrophe.

In addition to setting literal (constant) values, it is possible to copy a value from one attribute to another, as shown here. This query copies the value of object_name into title:

UPDATE dm_document OBJECT
SET subject = object_name
WHERE r_object_id = '0900001080002514'

The following query updates or sets repeating attributes:

UPDATE dm_document OBJECT
SET authors[0] = 'John',
SET authors[1] = 'Jane'
WHERE r_object_id = '0900001080002514'

Note that if a repeating property, like authors in this example, needs to be updated, an individual value needs to be set using this format – SET <property_name>[<index>] = >value>. <index> specifies the position in the list of repeating values for the property and the positions start with 0. However, if we just need to append values at the end of the list we can use this format – APPEND <property_name> = <value>. Multiple values can be appended by using multiple APPENDs within the same update query.

Repeating values can be removed using TRUNCATE, as shown in the following example:

UPDATE dm_document OBJECT
TRUNCATE authors
WHERE r_object_id = '0900001080002514'

This query removes all values for authors. In another variation, TRUNCATE authors [2] will remove all values at index 2 and higher.

DELETE query

A DELETE query has a similar structure to an UPDATE query except that there are no properties to be set. A DELETE query has the following format:

DELETE <type_name> OBJECT
WHERE <condition>

This query does not have many new features. In fact it is probably one of the simplest DQL queries. Again, the WHERE clause is optional but omitting it will result in all objects of the specifi ed type and its subtypes being deleted.

We need to be very careful when using DELETE queries because there is no easy way to undo such a deletion, which destroys the objects in the database.

Let's look at an example of the DELETE query:

DELETE dm_document OBJECT
WHERE owner_name = USER

This query deletes all current objects of type dm_document or any of its subtypes that are owned by the currently authenticated user and linked to the folder path /Temp. Note the keyword USER – it gets dynamically replaced with the currently authenticated user when the query is executed. Similarly, TODAY is a keyword that gets replaced with the date on which the query is executed. Some other useful keywords are YESTERDAY, TOMORROW, and NOW. These keywords are used in queries that utilize date or time values.

Further, note the use of the keyword AND—it enables conjunction of two conditions in the WHERE clause. OR and NOT can also be used in a similar manner.

The query also illustrates how to search certain folders for objects. The folder predicate can specify one or more folder paths and whether the subfolders of those folders should be included in the search recursively. Consider the modified version of this query:

DELETE dm_document OBJECT
WHERE owner_name = USER
AND FOLDER('/Temp/a','/Temp/b',DESCEND)

This query deletes all current objects of type dm_document or any of its subtypes that are owned by the currently authenticated user and linked to the folder path /Temp/a,/Temp/b or any subfolders of these paths. Note that multiple folders can be specified in the folder predicate and, optionally, DESCEND specifies that the subfolders should be included for all folder paths listed.


API methods can be issued via IAPI or Documentum Administrator in addition to programmatic access through DFC. IAPI can send individual method calls to the server. The API can be used to create scripts for administrative or development purposes. One of the most common uses of the API is to dump an object to view all of its properties. For example, the following API command prints the names and values for all the properties of the object identified by the given object ID:


API is no longer officially supported since most API methods have been mapped to DFC methods.

Documentum product notes

Normally, there is one content object per content file in the repository. However, if Content Storage Services are deployed and content duplication checking and prevention is enabled, multiple content objects may become associated with one content file. This happens when identical copies of a content file are found and removed.

Since objects, content objects, and content files can have many-to-many relationships; Content Server uses certain attributes on content objects to track these relationships. In order to uniquely identify these relationships, each content file is assigned a page number per parent object and the page number identifies this content file uniquely among the content files associated with that sysobject. Page numbers are useful for identifying the primary content that is the source of a rendition.

Typically, a rendition is associated with a parent object via a content object. However, renditions created by the media server can be alternatively connected to their source via a relation object.

High Volume Server provides transactional capabilities (as in business transactions) and features for rapid ingestion, efficient database storage, and reliable access to content. It can be used as a standalone repository for store-and-retrieval applications or as a transaction processing accelerator when coupled with a Documentum Content Server.

Each repository has some cabinets created for use by Documentum software. These cabinets are called system cabinets. Temp is a system cabinet which is frequently used for holding temporary objects. Aspects are a relatively new feature and its support in the product suite is still maturing.


In this article series, we learnt about the following concepts:

  • Objects and types
  • Type hierarchies and type categories
  • Object and content persistence
  • Lightweight and shareable object types
  • Aspects
  • Querying objects

You've been reading an excerpt of:

Documentum 6.5 Content Management Foundations

Explore Title