AnsweredAssumed Answered

Puzzling Behavior with IEdmBatchGet and IEdmFile::IsLocked

Question asked by Jim Sculley on Feb 21, 2016
Latest reply on Feb 23, 2016 by Jim Sculley

Like • Show 0 Likes0
Comment • 5

I'm using the following code in an EPDM add-in:

IEdmBatchGet batchGet = (IEdmBatchGet)vault.CreateUtility(EdmUtility.EdmUtil_BatchGet);
Array fileData = Array.CreateInstance(typeof(EdmSelItem), cncFileModelFilePairs.Count);
int index = 0;
foreach (Tuple<IEdmFile11, IEdmFile11> t in cncFileModelFilePairs)
{
    EdmSelItem nextItem = new EdmSelItem();
    nextItem.mlDocID = t.Item1.ID;
    nextItem.mlProjID = Utilities.getFileFolder(t.Item1).ID;
    fileData.SetValue(nextItem, index++);
}
batchGet.AddSelection((EdmVault5)vault, ref fileData);
EdmGetCmdFlags getOptions = EdmGetCmdFlags.Egcf_Lock /*| EdmGetCmdFlags.Egcf_RefreshFileListing*/;
batchGet.CreateTree(parentWindowHandle, (int)getOptions);
bool test = batchGet.ShowDlg(parentWindowHandle);
batchGet.GetFiles(parentWindowHandle);

Basically I have a list of pairs of files and I'm adding one file from each pair to the batch get which then checks the files out. This all appears to be successful, and the files are checked out when viewed in explorer. However, if I use IEdmFile::IsLocked in my add-in, it returns false indicating that the file is not checked out. If I write a simple little macro that calls IsLocked, and run it from SW, it returns true.

Lee CS Young Feb 23, 2016 3:24 PM

Correct Answer

That makes sense in it's implementation. You wouldn't want to be hitting the database for each property of the object. Try the Refresh method. (From the base IEdmObject5)

See the reply in context

No one else had this question

Outcomes

Artem Taturevych Feb 21, 2016 4:29 PM

Hi Jim,

Just thinking that this may be something with your pointer to IEdmFile5 not being refreshed correctly. Are you using the one from your 'cncFileModelFilePairs' array? Can you try to get a 'fresh' pointer either via GetFileFromPath or GetObject functions?

Thanks,

Artem

Actions

Lee CS Young Feb 22, 2016 10:34 AM

Have you tried calling RefreshFolder on the parent folder(s)? You could also set edmcmd.mlEdmRefreshFlags to 1 if it's relevant.

Actions

Jim Sculley Feb 23, 2016 11:41 AM

Artem and Lee:

Thanks for your input. After further investigation, I've reached the troubling conclusion that checking out files using IEdmBatchGet will not update the properties of existing IEdmFile objects that you may have. Even more troubling, any object retrieved via GetObject (or GetFileFromPath) has no relationship to other objects created in the same way using the same ID. For example:

IEdmFile11 testFile = (IEdmFile11)vault.GetObject(EdmObjectType.EdmObject_File, data[0].mlObjectID1);
IEdmFile11 testFile2 = (IEdmFile11)vault.GetObject(EdmObjectType.EdmObject_File, data[0].mlObjectID1);
testFile.LockFile(Utilities.getFileFolder(testFile).ID, parentWindowHandle);
testFile2.LockFile(Utilities.getFileFolder(testFile2).ID, parentWindowHandle);

After Line 3 executes, the IsLocked method will return true for testFile and false for testFile2 even though they are supposed to be representations of the same file in the vault. Line 4 then throws an exception because the file is already checked out. I'm guessing that the implementation of IsLocked (and many other properties) is simply returning the value of an internal variable instead of actually asking the system what the current status of the file is.

So, to solve my problem, I'll have to use GetFileList after every batch operation to rebuild my list of files and throw away any previously acquired IEdmFile5 objects.

Actions

Lee CS Young @ Jim Sculley on Feb 23, 2016 3:24 PM

That makes sense in it's implementation. You wouldn't want to be hitting the database for each property of the object. Try the Refresh method. (From the base IEdmObject5)

Actions

Jim Sculley @ Lee CS Young on Feb 23, 2016 5:05 PM

Lee CS Young wrote:

That makes sense in it's implementation. You wouldn't want to be hitting the database for each property of the object. Try the Refresh method. (From the base IEdmObject5)

I don't know. I'd rather have it be slow and consistent than fast and inconsistent. Also, the API docs for Refresh() say this (emphasis mine):

For performance reasons, some object properties might be cached in the object itself.

So, we know that some object properties are cached, but there is no indication of which ones. Therefore, you must program defensively and any time you access a property you need to call Refresh, which is no better than the system getting the data from the database on every property access.

In any event, Refresh is the correct answer, so you get the green star.

Actions

5 Replies

Artem Taturevych Feb 21, 2016 4:29 PM
Mark Correct
Correct Answer
Hi Jim,

Just thinking that this may be something with your pointer to IEdmFile5 not being refreshed correctly. Are you using the one from your 'cncFileModelFilePairs' array? Can you try to get a 'fresh' pointer either via GetFileFromPath or GetObject functions?

Thanks,
Artem
Like • Show 0 Likes0
Actions
Lee CS Young Feb 22, 2016 10:34 AM
Mark Correct
Correct Answer
Have you tried calling RefreshFolder on the parent folder(s)? You could also set edmcmd.mlEdmRefreshFlags to 1 if it's relevant.
Like • Show 0 Likes0
Actions
Jim Sculley Feb 23, 2016 11:41 AM
Mark Correct
Correct Answer
Artem and Lee:

Thanks for your input. After further investigation, I've reached the troubling conclusion that checking out files using IEdmBatchGet will not update the properties of existing IEdmFile objects that you may have. Even more troubling, any object retrieved via GetObject (or GetFileFromPath) has no relationship to other objects created in the same way using the same ID. For example:
```
IEdmFile11 testFile = (IEdmFile11)vault.GetObject(EdmObjectType.EdmObject_File, data[0].mlObjectID1);
IEdmFile11 testFile2 = (IEdmFile11)vault.GetObject(EdmObjectType.EdmObject_File, data[0].mlObjectID1);
testFile.LockFile(Utilities.getFileFolder(testFile).ID, parentWindowHandle);
testFile2.LockFile(Utilities.getFileFolder(testFile2).ID, parentWindowHandle);
```
After Line 3 executes, the IsLocked method will return true for testFile and false for testFile2 even though they are supposed to be representations of the same file in the vault. Line 4 then throws an exception because the file is already checked out. I'm guessing that the implementation of IsLocked (and many other properties) is simply returning the value of an internal variable instead of actually asking the system what the current status of the file is.

So, to solve my problem, I'll have to use GetFileList after every batch operation to rebuild my list of files and throw away any previously acquired IEdmFile5 objects.
Like • Show 0 Likes0
Actions
- Lee CS Young @ Jim Sculley on Feb 23, 2016 3:24 PM
  Unmark Correct
  Correct Answer
  That makes sense in it's implementation. You wouldn't want to be hitting the database for each property of the object. Try the Refresh method. (From the base IEdmObject5)
  Like • Show 0 Likes0
  Actions
  - Jim Sculley @ Lee CS Young on Feb 23, 2016 5:05 PM
    Mark Correct
    Correct Answer
    Lee CS Young wrote:
    
    That makes sense in it's implementation. You wouldn't want to be hitting the database for each property of the object. Try the Refresh method. (From the base IEdmObject5)
    I don't know. I'd rather have it be slow and consistent than fast and inconsistent. Also, the API docs for Refresh() say this (emphasis mine):
    
    For performance reasons, some object properties might be cached in the object itself.
    
    So, we know that some object properties are cached, but there is no indication of which ones. Therefore, you must program defensively and any time you access a property you need to call Refresh, which is no better than the system getting the data from the database on every property access.
    
    In any event, Refresh is the correct answer, so you get the green star.
    Like • Show 0 Likes0
    Actions

Puzzling Behavior with IEdmBatchGet and IEdmFile::IsLocked

Outcomes

Related Content

Recommended Content