DON’T EVER DO THIS!
I am sure I have whined about this before but this is one common mistake that newbies to Documentum insist on committing over and over again. More often than not against the advice of others. I just saw it again!
You’re writing an application that needs a key to reference a related object – say from a fragment that is stored in the XML content. So what do you do? Store the object ID of course – it’s the unique identifier right? Well yes – for the docbase – not your aplication.
When (not if) you have to rehost the content for an upgrade or migration down the road – the target will get a new object ID. Even if you use the same docbase ID – when you reload the content to the new target – it gets a new ID. You can NEVER guarantee that an object ID will be immutable. If you have persisted that ID in a content file for any reason – or even if you stored it as metadata on the object- you have designed yourself into a potentially expensive headache.
There must be a dozen ways to do this better – just remember – NEVER store the r_object_id somewhere yourself. If you need a unique key – don’t be lazy – make your own. Yes – I know Documentum does it – but they have to figure out how to implement upgrades and will accomodate the needs of the repository- not your app. Why create this problem for your successors if it can easily be avoided?
Lee Dallas
Marko Sillanpää