Opinions and discussion on content management and document management by one of the biggest guys in the business. *Measured by combined weight

Embedding r_object_id in content


Follow Marko

Follow Lee

  • watched @ticktickboom with a bunch of GenZ's last night and none of them knew who Stephen Sondheim was.this made me sad 3 weeks ago


The opinions shared here represent those of the contributor themselves and not those of their employers nor that of Big Men On Content as a whole.


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?

%d bloggers like this: