Two other bloggers (doquent and Rajendra ) have been pondering why it is that user_name was the foreign key for dm_user instead of the r_object_id of the user object. They are looking for a logical reason why you would do that, but unfortunately they are trying to interpret it with today’s understanding and common design practices.
Why would you do it this way today? – You wouldn’t – Nobody would – Not even Documentum. This part of the data model is some of the oldest design in the Documentum architecture. It predates workflows, lifecycles, ldap, extended permissions, and ACL’s. It is in the very heart of the application from the days of OGW permissions, NFS checkout directories, Workspace on UNIX, optical file stores and other dinosaurs.
One suggestion in the thread was that not using r_object_id was intentional because that field didn’t used to be immutable. Well – it’s really not immutable now and you should never assume it will be. Especially in customizations. There are too many things that can alter it – dump and load, replication, certain DR strategies… What Documentum does with it is their business as I expect them to govern referential integrity for the “r_” attributes.
“r_” used to mean not modifiable by the user – you know , like “read only.” It does not mean immutable. user_name is not prefixed. Neither is owner_name – meaning that there were (and are) API’s and specific user actions that could change the value.
In the early days, every byte stored was costly – what’s worse is that database indexes on string values were painful and expensive. So much so r_object_id_i was used as an internal numeric equivalent through EDMS 98. The oldest data model I am familiar with had both user_os_name and user_name. user_domain didn’t exist then and user_login_name was not introduced until D5.(I think) That one is still not used correctly in most installs because lazy people won’t take the time to understand it.
The orginal modelers had to choose something as a foreign key to dm_user from dm_sysobject. More than likely the denormalized use of the unstructured char user_name rather than a key (which then would be numeric) was a matter of expedience and usability rather than any type of thoughtful optimization. We are still paying for it. It made sense at the time but now it’s just something you have to learn to work around.
The bloggers reference a logging bug where user_name containing special characters errors because log files are generated using that value and some O/S’s will choke on certain characters if they appear in the name. This is an indication that the engineers in Documentum (particularly those not on the server team) don’t always take the time to understand their own product- how could they – the thing is so huge it takes years to understand the innards of this beastie.
Still – this is a real basic blunder for whoever wrote the logging code – one a certified EMC developer would surely know to avoid. hmmm…
Lee Dallas
Marko Sillanpää
Lee,
Thanks for providing the historical insight into the issue – it puts multiple aspects into perspective. I also want to clarify that my post was intended to share certain pitfalls related to the issue and not to criticize Documentum.
On a separate note, I disagree with your comment about “certified EMC developers”. I have seen developers with EMC certification who have zero hands-on experience – so it is difficult to generalize. I do agree about the complexity of Documentum – that is probably one of the reasons for the relative dearth of good Documentum professionals.
Hey Pawan, Clarification noted.
As to the certification point – to quote Miley Cyrus – “everybody makes mistakes, everybody has those days.” Maybe I just expect too much.
Lee,
Thanks for giving in depth details on my post. I clarity given by other bloggers on this pitfall of Documentum is highly appreciable. I see very valid points coming out. Redesigning this pitfall with newer approach would have enormous ramifications.