Has anyone tried to create a real 'Move' in PW, not the standard Copy and Delete 'Move' delivered in PW?

Hello,

I was wondering, has anyone tried to create a real 'Move'  in PW, not the standard Copy and Delete 'Move' delivered in PW? 

If you copy a file from one folder to another folder on the same partition, it is inearly nstant as it just involves a move in the folder tables.
That's on most OSes and DBs.

That doesn't happen in Projectwise and Move only works on a single file too.
:-(
In PW,  MOVE transfers the data into a new Blob then deletes the original blob.
If moving a folder or large file this takes ages and can be prone to port errors.
You have to use Cut n Paste to move multiple files.
So you end up checking out and checking in models to move them.
Copying them to the local PW Cache and then uploading them back to the server.

I suspect a real "in place" Move function could be done by just changing the folder id and possibly the relevant folder path  and a 'refresh.

Has anyone tried creating a Move like this before?

There a lots of M$ "Connector", but there are all layer applications and would just utilise the PW Move.
I think it would need PW SDK or some undocumented calls to rewrite the Folder id/path.

Any hints/suggestions  of possible example SDKs or other utilities that might make this possible.

Power shell PW  is just another layer on top, so the move functions in it does the same as PW Move.


Parents
  • ,

    Your suspicion that a "in place move" could be done by just changing the folder id is incorrect. The relevant folder path is not stored anywhere (other than perhaps in a data dictionary in memory), it is built dynamically as each folder has a "parent folder" and the path is built by "walking up" the tree branches to the root.

    If you were to hack the database (not supported or recommended), and changed the folder id of a document, this would not work because the file's location is in a storage area where the parent folder (OS folder) contains the folder id of the document.  You would also have to move the file from that OS/File location to where ProjectWise expects it to be. 

    If you did change the folder id by hacking the database without actually moving the file to the expected location in the storage area, ProjectWise would report the file as "missing".  This would also have the potential to have a conflict with another document ID in the "target" ProjectWise folder and the update could fail (key violation).  If you are lucky enough to have a document id that is not used in the target folder, then other data corruption is very likely.  The other data corruption could be of document attributes, reference files, flat sets, missing audit trail records, document security ACLs, etc..  If you were to assign an "unused" document ID to the "moved" document, then the system that tracks which IDs are available would likely get corrupted.  

    Another area of data corruption would be all the data caches that ProjectWise uses to optimize performance.  If you bypass the ProjectWise APIs and update the database directly, "ProjectWise" is not aware of the change and would not "know" that the document/file has been "moved", at least not until the next time it needs to update the relevant data caches on clients and on the server.

    There is no way to "improve" the document move command using the ProjectWise SDK.  The APIs abstract the move and this behavior is what all ProjectWise clients use to move a document/file.

    The best you could do is ask ProjectWise development to see if they can improve the performance of a document move command when the file is on the same file system and move the file at the file system level.  As you noted, the current move command does in fact, copy the document/file and then deletes the original, but in a transaction that ProjectWise manages to account for "failures" that might occur during the process.

    You should also note that you cannot move a document without all of its versions because of the way ProjectWise keeps track of versions.

    You mention "blobs" for the file system.  I assume that this datasource is perhaps using an Azure storage system that mimics a traditional file system.  I don't know if a move in this case would be possible at the "blob" level or not, or if the performance could be improved.  At the ProjectWise API level, it all looks the same, i.e. the storage areas and how files are created, copied, moved, or deleted is abstracted and the underlying code implements the appropriate behavior for the type of storage areas involved.

Reply
  • ,

    Your suspicion that a "in place move" could be done by just changing the folder id is incorrect. The relevant folder path is not stored anywhere (other than perhaps in a data dictionary in memory), it is built dynamically as each folder has a "parent folder" and the path is built by "walking up" the tree branches to the root.

    If you were to hack the database (not supported or recommended), and changed the folder id of a document, this would not work because the file's location is in a storage area where the parent folder (OS folder) contains the folder id of the document.  You would also have to move the file from that OS/File location to where ProjectWise expects it to be. 

    If you did change the folder id by hacking the database without actually moving the file to the expected location in the storage area, ProjectWise would report the file as "missing".  This would also have the potential to have a conflict with another document ID in the "target" ProjectWise folder and the update could fail (key violation).  If you are lucky enough to have a document id that is not used in the target folder, then other data corruption is very likely.  The other data corruption could be of document attributes, reference files, flat sets, missing audit trail records, document security ACLs, etc..  If you were to assign an "unused" document ID to the "moved" document, then the system that tracks which IDs are available would likely get corrupted.  

    Another area of data corruption would be all the data caches that ProjectWise uses to optimize performance.  If you bypass the ProjectWise APIs and update the database directly, "ProjectWise" is not aware of the change and would not "know" that the document/file has been "moved", at least not until the next time it needs to update the relevant data caches on clients and on the server.

    There is no way to "improve" the document move command using the ProjectWise SDK.  The APIs abstract the move and this behavior is what all ProjectWise clients use to move a document/file.

    The best you could do is ask ProjectWise development to see if they can improve the performance of a document move command when the file is on the same file system and move the file at the file system level.  As you noted, the current move command does in fact, copy the document/file and then deletes the original, but in a transaction that ProjectWise manages to account for "failures" that might occur during the process.

    You should also note that you cannot move a document without all of its versions because of the way ProjectWise keeps track of versions.

    You mention "blobs" for the file system.  I assume that this datasource is perhaps using an Azure storage system that mimics a traditional file system.  I don't know if a move in this case would be possible at the "blob" level or not, or if the performance could be improved.  At the ProjectWise API level, it all looks the same, i.e. the storage areas and how files are created, copied, moved, or deleted is abstracted and the underlying code implements the appropriate behavior for the type of storage areas involved.

Children
No Data