Where is the file stored?

When a document is imported into document the metadata goes into the database and the file goes into some content store, typically the filesystem. The users are not bothered about where the content server will store this file but the content server needs to make that decision.

A Documentum repository specifies various storage areas that are available via objects of type dm_store. Each dm_store object holds enough information for the content server to get to the physical location identified for the storage area. The relative path from there is figured out based on the object ID [of the content object as clarified in one of the comments]. Therefore the content server needs to identify the storage area to use before it can store the file.

Here is how it is decided:

1. If Content Storage Services (CSS) are in use it tries to resolve this by applying the policies in place using the CSS algorithm. If CSS is not in use or if it fails to resolve the storage area using this algorithm it tries the next step.
2. Default Storage Algorithm
   1. Primary Content
      1. If the file is primary content for the sysobject, this approach is used.
      2. If a storage type is set on the sysobject that is used. Otherwise,
      3. If a storage type is set on the format that is used. Otherwise,
      4. If a default storage type is set on the object type that is used. Otherwise,
      5. Turbo storage is used (stored in database)
   2. Rendition
      1. If the file is a rendition of a primary content this approach is used
      2. If the storage arg of addrendition is specified, that is used. Otherwise,
      3. If a storage type is set on the format that is used. Otherwise,
      4. Storage are for the primary content (dmr_content.rendition=0) is used

Stay away from QA!

Customer: “All, please stay from QA today since group X is testing application AX.”

Everyone finds something else to do and the application AX passes the tests gloriously. Application AX goes to production. Cheers!

A few days later …

End User: “Application AX is behaving weirdly in this scenario. Please help!”

The support team starts troubleshooting. The vendor who developed the application is contacted about the problem.

Vendor: “It was working in QA so your production environment must be bad.”

Blame first, troubleshoot later. It is impossible that QA could be bad and production good. Of course, the tests were exhaustive and covered every possible condition in every branch of code. And the testers are always able to perform every step faithfully. Buggy code? Ours?

The support team generates logs and provides to the vendor. It turns out to be a bug in the code that was not exposed due to the clean and isolated operation in QA. A bug so egregious that it would be a miracle to hide in the production environment simply because there would be other applications and users interacting with the infrastructure used by application AX.

Of course, some points could be made for providing a “controlled” environment for testing. I would be much happier if the application broke in QA and worked in production. When did passing become the goal of testing?

PS: Vendors should just visualize the fate of Enron when they start believing that they are the smartest guys in the room.