phpcr/src/PHPCR/WorkspaceInterface.php

Unlike the signature of copy that copies between workspaces, this method does not assign new identifiers to the newly cloned nodes but preserves the identifiers of their respective source nodes. This applies to both referenceable and non-referenceable nodes.

In some implementations there may be cases where preservation of a non-referenceable identifier is not possible, due to how non-referenceable identifiers are constructed in that implementation. In such a case this method will throw a RepositoryException.

If removeExisting is true and an existing node in this workspace (the destination workspace) has the same identifier as a node being cloned from srcWorkspace, then the incoming node takes precedence, and the existing node (and its subgraph) is removed. If removeExisting is false then an identifier collision causes this method to throw an ItemExistsException and no changes are made.

If successful, the change is persisted immediately, there is no need to call save.

The destAbsPath provided must not have an index on its final element. If it does then a RepositoryException is thrown. If ordering is supported by the node type of the parent node of the new location, then the new clone of the node is appended to the end of the child node list.

This method cannot be used to clone just an individual property; it clones a node and its subgraph.

PHP Notice: The JCR method is called clone, but that is a reserved keyword in PHP, thus we named the method cloneFrom.

This method copies the subgraph rooted at, and including, the node at $srcWorkspace (if given) and $srcAbsPath to the new location in this Workspace at $destAbsPath.

This is a workspace-write operation and therefore dispatches changes immediately and does not require a save.

When a node N is copied to a path location where no node currently exists, a new node N' is created at that location. The subgraph rooted at and including N' (call it S') is created and is identical to the subgraph rooted at and including N (call it S) with the following exceptions: - Every node in S' is given a new and distinct identifier - or, if $srcWorkspace is given - Every referenceable node in S' is given a new and distinct identifier while every non-referenceable node in S' may be given a new and distinct identifier. - The repository may automatically drop any mixin node type T present on any node M in S. Dropping a mixin node type in this context means that while M remains unchanged, its copy M' will lack the mixin T and any child nodes and properties defined by T that are present on M. For example, a node M that is mix:versionable may be copied such that the resulting node M' will be a copy of N except that M' will not be mix:versionable and will not have any of the properties defined by mix:versionable. In order for a mixin node type to be dropped it must be listed by name in the jcr:mixinTypes property of M. The resulting jcr:mixinTypes property of M' will reflect any change. - If a node M in S is referenceable and its mix:referenceable mixin is not dropped on copy, then the resulting jcr:uuid property of M' will reflect the new identifier assigned to M'. - Each REFERENCE or WEAKEREFERENCE property R in S is copied to its new location R' in S'. If R references a node M within S then the value of R' will be the identifier of M', the new copy of M, thus preserving the reference within the subgraph.

When a node N is copied to a location where a node N' already exists, the repository may either immediately throw an ItemExistsException or attempt to update the node N' by selectively replacing part of its subgraph with a copy of the relevant part of the subgraph of N. If the node types of N and N' are compatible, the implementation supports update-on-copy for these node types and no other errors occur, then the copy will succeed. Otherwise an ItemExistsException is thrown.

Which node types can be updated on copy and the details of any such updates are implementation-dependent. For example, some implementations may support update-on-copy for mix:versionable nodes. In such a case the versioning-related properties of the target node would remain unchanged (jcr:uuid, jcr:versionHistory, etc.) while the substantive content part of the subgraph would be replaced with that of the source node.

The $destAbsPath provided must not have an index on its final element. If it does then a RepositoryException is thrown. Strictly speaking, the $destAbsPath parameter is actually an absolute path to the parent node of the new location, appended with the new name desired for the copied node. It does not specify a position within the child node ordering. If ordering is supported by the node type of the parent node of the new location, then the new copy of the node is appended to the end of the child node list.

This method cannot be used to copy an individual property by itself. It copies an entire node and its subgraph (including, of course, any properties contained therein).

The new workspace is empty, meaning it contains only root node.

If srcWorkspace is given:<br/> Creates a new Workspace with the specified name initialized with a clone of the content of the workspace srcWorkspace. Semantically, this method is equivalent to creating a new workspace and manually cloning srcWorkspace to it; however, this method may assist some implementations in optimizing subsequent NodeInterface::update() and NodeInterface::merge() calls between the new workspace and its source.

The new workspace can be accessed through a login specifying its name.

Returns a string array containing the names of all workspaces in this repository that are accessible to this user, given the Credentials that were used to get the Session to which this Workspace is tied. In order to access one of the listed workspaces, the user performs another RepositoryInterface::login(), specifying the name of the desired workspace, and receives a new Session object.

This the name used in Repository->login.

In level 2 repositories the NamespaceRegistry can also be used to change the namespace mappings.

There is one node type registry per repository, therefore the NodeTypeManager is not workspace-specific; it provides introspection methods for the global, repository-wide set of available node types. In repositories that support it, the NodeTypeManager can also be used to register new node types.

If the incoming XML does not appear to be a JCR system view XML document then it is interpreted as a document view XML document.

Changes are made directly at the workspace level, without going through the Session. As a result, there is not need to call save. The advantage of this direct-to-workspace method is that a large import will not result in a large cache of pending nodes in the Session. The disadvantage is that invalid data cannot be imported, fixed and then saved. Instead, invalid data will cause this method to throw an InvalidSerializedDataException. See SessionInterface::importXML() for a version of this method that does go through the Session.

The flag $uuidBehavior governs how the identifiers of incoming (deserialized) nodes are handled. There are four options:

• ImportUUIDBehavior::IMPORT_UUID_CREATE_NEW: Incoming nodes are assigned newly created identifiers upon addition to the workspace. As a result identifier collisions never occur.
• ImportUUIDBehavior::IMPORT_UUID_COLLISION_REMOVE_EXISTING: If an incoming node has the same identifier as a node already existing in the workspace then the already existing node (and its subgraph) is removed from wherever it may be in the workspace before the incoming node is added. Note that this can result in nodes "disappearing" from locations in the workspace that are remote from the location to which the incoming subgraph is being written. If an incoming node has the same identifier as the existing root node of this workspace then
• ImportUUIDBehavior::IMPORT_UUID_COLLISION_REPLACE_EXISTING: If an incoming node has the same identifier as a node already existing in the workspace then the already existing node is replaced by the incoming node in the same position as the existing node. Note that this may result in the incoming subgraph being disaggregated and "spread around" to different locations in the workspace. In the most extreme edge case this behavior may result in no node at all being added as child of parentAbsPath. This will occur if the topmost element of the incoming XML has the same identifier as an existing node elsewhere in the workspace.
• ImportUUIDBehavior::IMPORT_UUID_COLLISION_THROW: If an incoming node has the same identifier as a node already existing in the workspace then an ItemExistsException is thrown.

If successful, the change is persisted immediately, there is no need to call save. Note that this is in contrast to Session->move($srcAbsPath, $destAbsPath) which operates within the transient space and hence requires a save.

The identifiers of referenceable nodes must not be changed by a move. The identifiers of non-referenceable nodes may change.

The destAbsPath provided must not have an index on its final element. If it does then a RepositoryException is thrown. Strictly speaking, the destAbsPath parameter is actually an absolute path to the parent node of the new location, appended with the new name desired for the moved node. It does not specify a position within the child node ordering. If ordering is supported by the node type of the parent node of the new location, then the newly moved node is appended to the end of the child node list.

This method cannot be used to move just an individual property by itself. It moves an entire node and its subgraph (including, of course, any properties contained therein).

The identifiers of referenceable nodes must not be changed by a move. The identifiers of non-referenceable nodes may change.

This is a workspace-write method and therefore is dispatched immediately. A save is not required. In the absence of a transaction, the changes made by this method will also be persisted immediately. In the presence of a transaction the changes will be persisted upon commit of the transaction.

If a node with same-name siblings is removed, this decrements by one the indices of all the siblings with indices greater than that of the removed node. In other words, a removal compacts the array of same-name siblings and causes the minimal re-numbering required to maintain the original order but leave no gaps in the numbering.

A ReferentialIntegrityException will be thrown if the specified item or an item in its subgraph is currently the target of a REFERENCE property located in this workspace but outside the specified item's subgraph and the current Session has read access to that REFERENCE property.

A ConstraintViolationException will be thrown either on dispatch or on persist, if removing the specified item would violate a node type or implementation-specific constraint. Implementations may differ on when this validation is performed.

A VersionException will be thrown either on dispatch or on persist, if the parent node of the specified item is read-only due to a checked-in node. Implementations may differ on when this validation is performed.

A LockException will be thrown either on dispatch or on persist, if a lock prevents the removal of the specified item. Implementations may differ on when this validation is performed.

A PathNotFoundException will be thrown either on dispatch or on persist, if no accessible item is found at at $absPath.

A AccessDeniedException will be thrown either on dispatch or on persist, if the specified item or an item in its subgraph is currently the target of a REFERENCE property located in this workspace but outside the specified item's subgraph and the current Session does not have read access to that REFERENCE property.