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):
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.