DFC 6.5 SP2 - checkout / checkin and replace content

Hi Fenil,

The procedure you have mentioned in standard process. Please see the below api for CheckIn:

checkin

IDfId checkin(boolean keepLock, String versionLabels) throws DfException

Creates a new version of this object and removes the lock from the previous version.

To use the checkin method, the following conditions must be met:

• The object must have been retrieved from the repository with a checkout method.
• The user must have at least Version permission on the object.
• The user must have at least Write permission on the cabinet or folder in which the object is stored if the repository is running with folder security.

Note: Folder security is on by default when a repository is configured. The folder security setting is recorded in the folder_security attribute of the docbase config object. The checkin method unlocks an object and saves any changes you may have made to either its attributes or its content.  (Note that to make changes to the content, you must issue explicit methods, such as getFile and setFile, to get and set the content after you checkout the object and before you issue the checkin).

Executing this method clears the object's r_lock_machine, r_lock_owner, and r_lock_date attributes and sets the a_archive attribute to FALSE. Additionally, if the object is a policy object, the method sets the r_definition_state to DRAFT for the new version and clones the following attributes:

• entry_criteria_id
• user_criteria_id
• action_object_id
• user_action_id
• type_override_id

The primary content associated with the new version is stored in the storage area specified in default_storage attribute of the content's dm_format object if that attribute is set. If the storage area is not defined in the format object, the content is stored in the storage area identified in the default_storage attribute of the object's object type. You can override either default storage area by executing an explicit method to set the a_storage_type attribute of the object before the check in.

The following code example demonstrates how to checkin an object using the default version labels, and to not retain a lock on the newly created version:

---

 IDfSysObject sysObj = (IDfSysObject)sess.getObject(new DfId("0900d5bb8001fd49")); if (sysObj.isCheckedOut()) { sysObj.setFile(sysObj.getObjectName()); IDfId newSysObjId = sysObj.checkin(false, ""); } 

---

Parameters:

keepLock - set to true to place a lock on the                          newly created version.

versionLabels - defines the version label for the new version.                                                        You can specify more than one label.  If you do                                                        not define a label, the server automatically gives                                                        the new version an implicit version label and the                                                        symbolic label "CURRENT".

Returns:

the object id of the new version of the object.

Throws:

<a _jive_internal="true" href="/com/documentum/fc/common/DfException.html" title="class in com.documentum.fc.common">DfException</a> - if a server error occurs.

Thanks and Regards,

Amit G

You can use IDfSysobject.bindFile if your sysobjects have same content-type

PanfilovAB wrote:

You can use IDfSysobject.bindFile if your sysobjects have same content-type

PanfilovAB - Just for my info. What will happen to object A's content if you update (check-in with new content) content of objects B, which are bind? Will it then split the content in to two separate physical content? or it will change the content of second object as well with the same content and keeps only single physical content at all times?

Thanks for the link. but it still doesn't address the question (if the content of second object is replaced as well when doing a check-in on first object).

Content Server always creates a new dmr_content object (even if you checkin as same version) and never overwrites files on the file system. So if two objects share a dmr_content file, after changing one of them, the latter will point to a new dmr_content object and file. So there are no issues here.

In other words, bindfile is just an technical optimisation and doesn't have any functional impact.

So I did a few test myself and this is what I observed.

1)

object 1 = TestA (Doc1.pdf)

object 2 = TestB (Doc2.pdf)

2)

did a bindfile of the two objects TestA as target. Now

object 1 = TestA (Doc2.pdf)

object 2 = TestB (Doc2.pdf)

3)

Now I did a checkout of TestB (with content Doc3.pdf), and result

object 1 = TestA (Doc2.pdf)

object 2 = TestB (Doc3.pdf)

4)

Now I did a check out of TestA (with content Doc4.pdf), and result

object 1 = TestA (Doc4.pdf)

object 2 = TestB (Doc3.pdf)

So, it seems that when bind happens, both objects have the same content, but when any one of the objects is checked in with new content, they no longer have the same content. Exactly what you two suggested. Thanks guys.

But one thing is still not clear to me. In step 2) when we do bindfile, does the content server create a copy of the physical document (Doc2.pdf) in the filestore? or the same document is referenced by both objects?