dm_notes: Documentum Notes

July 10, 2008

r_object_id Vs user_name of dm_user which is better?

Filed under: documentum — Tags: , — Raj V @ 3:22 am

I always have an unanswered question, when ever I see the “r_accessor_name”, “owner_name”, authors, users_names (of a dm_group) and at many places where ever CS refers to a user. Documentum stores the “user_name” in all the above attributes. Typically the “user_name” is “Last name, First Name” and “user_os_name” & “user_login_name”  is generally the unique login user_id in a corporate network.

Why doesn’t CS store the r_object_id of the user where it has to refer to a user, as it is unique, immutable in a repositories lifetime and is also maintainable.
dm_user is a content less object,  It can’t be version-ed.  (You can however update the object properties but you can’t create version this object; i_vstamp tracks the no. of updates) .
So invariably your r_object_id always refer to the same object (version).

If the CS would have used the r_object_id instead of user_name across all objects, it would have been more manageable.

Here are few I believe that create trouble:

  • A user name correction or a rename would have been easier. (Ex.: The maiden name change due to marital status or mis-spelled name)
    • Need to change the name on all objects or deactivate the user and create the same user as a new user
    • Need to change the name in all groups defined.
    • A scenario where there are 2 users with the same name.
  • User deletion would have been easier and maintainable. ( Delete the user and run a script to remove all the orphan object ids referred by the objects)
  • Better disk space utilization. Consider a scenario where there are 10 users (authors) on each object and there are 1000 objects in the repository. Assume an average user_name attribute takes 20 bytes (this would be the minimum I guess). So the space consumed by these users for each version of the object is 10* 20  bytes * 1000 objects = 200,000 bytes. Same scenario with r_object_id 10 users * 16 bytes * 1000 objects = 160,000 bytes a saving of 4000 bytes (4K approx).  Additional versions would save further on space. ( Disk space is inexpensive now but how about maintainability)

The only reason I see the benefit in having the user_name across all objects is the “performance factor”, the CS doesn’t require to fetch the Full name everytime you access a object as it is directly stored currently. But the same could easily be atained through object caching (already supported by the server).

Why it has been designed this way any specific reason for this or it was just overlooked during intial design phase?

Expert comments are welcome.

December 5, 2007

DQL to list of users in a group

Filed under: dm_group, dm_user, dql — Tags: , , — Raj V @ 5:42 pm

DQL to query the list of users in a group

  • select users_names from dm_group where group_name = ‘mygroup’;

DQL to query the list of active users (Users who can log in) in a group:

  • select user_name from dm_user where user_state = 0 and user_name in (select users_names from dm_group where group_name = ‘mygroup’);
    user_state of dm_user indicates the user’s current state.
    Valid alues are:

    • 0, indicating a user who can log in.
    • 1 indicating a user who cannot log in.
    • 2 indicating a user who is locked.

October 5, 2007

What does Documentum recommend about deleting users?

Filed under: support note — Tags: , — Raj V @ 11:53 am

Note: Every SysObject or SysObject subtype in the Docbase has an attribute called owner_name that identifies the user who owns the object. We suggest deactivating users, rather than deleting them based on the following issues:

– Before deleting a user from a Docbase, you must update the objects created by the deleted user to change the owner_name to identify a different user. You do not need to change the owner_name if you deactivate the user.

– When you delete a user, the server does not remove the user’s name from objects in the Docbase such as groups and ACLs. It is possible to delete a user, and then re-create the user with the same name. However, if you add a new user with the same name as a previously deleted Docbase user, the new user will inherit the group membership and object permissions of the previously deleted user.

– You cannot delete the Docbase owner, installation owner, or yourself.

– When you no longer need a user account, deactivate the user. Deactivating a user is better than deleting a user. Once a user is deactivated in a Docbase, that user will not be able to log in to that Docbase. You must have Sysadmin or Superuser privileges to deactivate or reactivate a user.

– You cannot change the login state of the Docbase owner, installation owner, or yourself. You deactivate and reactivate users by changing the user’s login state using Documentum Administrator, DQL or the API.

– By default, users are active when you create them, so you do not need to activate new users. The user’s login state is tracked by the user_state attribute of the dm_user object. If you deactivate a user who is currently logged in, the change takes affect when the user next logs in.

– If necessary, a user with Superuser privileges can use a ticket to log in as a deactivated user, and a user with Superuser privileges can add a deactivated user to a group

NOTE: You can rename users to another existing user if necessary; this then deletes the original user. In our application it is our standard that every object should have someone who it belongs to, using renaming instead of deactivating accounts accommodates this requirement.

The users are created and authenticated at the OS level.

This is the way I intend to do this is by making all the object owners a user e.g. “system” and then we would delete the users that are not required from the Documentum system. This way all object owners would be “system” and whether or not the user is deleted from Documentum would not impact the system.

Note: This is a support note I found floating in yahoo groups. I am not sure of the support note no.  The EMC copyrights apply to this Note as it is authored by EMC.

Blog at