A number of different methods in the API transfer node state from one location to another. They often differ in how they treat the UUID of the node. Some methods always behave the same way in this regard, others have various options that control their behavior. The following table summarizes the behaviors of the methods.
|
Method |
New UUID |
Keep UUID (3 behaviors on conflict) |
Comments |
||
|
Throw |
Remove from existing location |
Replace at existing location |
|||
|
Workspace.copy |
yes |
no |
no |
no |
copy (both within and between workspaces) simply creates a new UUID for any referenceable nodes it copies. |
|
Session.save |
no |
no |
no |
yes |
save pushes items to the persistent workspace, replacing existing items using UUID matching, wherever they may be in terms of path (non-referenceable nodes are kept bound to their UUID-bearing ancestor, however). |
|
Node.update |
no |
no |
no |
yes |
update pulls the state of this node from another workspace using UUID matching, regardless of where (in terms of path) the source node is in the source workspace. |
|
Workspace.clone |
no |
yes |
yes |
no |
clone keeps UUIDs. There are two options to deal with cases where this workspace already contains a node with the same UUID as one being cloned over: either throw, or remove the existing node in this workspace. |
|
Node.restore |
no |
yes |
yes |
no |
restore and restoreByLabel keep UUIDs. Similar to clone, there are two options to deal with cases where this workspace already contains a node with the same UUID as being copied in as part of a restored version: either throw, or remove the existing node in this workspace. |
|
Workspace.importXML |
yes |
yes |
yes |
yes |
All four options are supported. |