CHANGE OBJECT – good, but not great

Documentum provides application developers the ability to create custom types and further supports the ability to subtype existing system and custom types. This kind flexibility sometimes leads to incorrect object hierarchy design by novice developers.  Instead of analyzing whether attributes should be at the parent or child level, developers haphazardly create custom objects and hope for the best. The impact of bad object design is inconsequential during development; however, once an object hierarchy design is put into production and content is associated with it, the consequences can become significant. Imagine having thousands of documents associated to the wrong object type.

Luckily, Documentum provides the ability to change an object’s type in bulk. This feature is supported via CHANGE OBJECT[S] DQL statement. The major caveat of this is that the new type to be changed to must be a subtype or supertype of the current type. This means it is not possible to change an object’s type to a sibling type. Let’s use an example for clarity. Suppose you have two custom types derived from dm_document (parent type):

        dm_document
                 |
custom_a—–custom_b

custom_a has custom string attribute attr_a
custom_b has custom string attribute attr_b

To change 1000 custom_a objects to custom_b, requires that you change custom_a objects to dm_document first and then to custom_b.  This seems straightforward, except that all values for attr_a are lost.

In an ideal world, CHANGE OBJECT function would support attribute mapping like most ETL (Extract, Transform, Load) tools do.  This would allow changing object types without the loss of data.  Since this is not currently supported, developers should spend more time in designing their object hierarchy before jumping into coding.  Who knows…a stitch in time saves nine.

Advertisements

2 responses to “CHANGE OBJECT – good, but not great

  1. Hi johnnygee,

    Just curious, but from an architect perspective, how would you propose to solve this issue of loss of data? Why are attribute values lost when converting from custom type to another?

  2. Hi spacegiblet,
    Let me answer the last question first. Attribute values will be lost moving up the object hierarchy if the custom attribute (column) is defined for the child object type. Since the parent object type does not have a “comparable” attribute to store the custom attribute data, it gets lost. How to solve this problem? A lot of ETL tools have mechanisms to store data in a temporary table/cache. If the Content Server supported this kind data cache table, then data loss would not be an issue. Of course, as a developer, you can create your own temp table while you update object type definitions.

Leave a Reply

Please log in using one of these methods to post your comment:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s