Fork me on GitHub

Referenceable Nodes

Overview

The JCR 2.0 specification defines referenceable nodes. Those carry a jcr:uuid property which uniquely identifies a node within a repository workspace. Each FileVault export contains this (protected) property jcr:uuid as well which is important to keep referential integrity. The import behavior depends on the used FileVault version.

Import behavior prior FileVault 3.5.2

The ids of referenceable nodes are only kept during import when a node with the same name (independent of its jcr:uuid value) does not yet exist in the repository. For existing nodes the ids are never updated with the value from the package. They either get a new id or keep their old one (in case the old node was already a referenceable node). In case of conflicts with nodes at a different path, the existing conflicting node is removed but all its references are kept (i.e. they point to a different path after the import).

Import behavior since FileVault 3.5.2

Since version 3.5.2 (JCRVLT-551) FileVault tries to use the jcr:uuid of the node in the package even if a same named node does already exist. In case this cannot be achieved while keeping referential integrity of old and new nodes an exception is thrown. Existing nodes with conflicting identifiers or reference properties towards conflicting identifiers are removed in advance if they are contained in the filter rules to reduce the conflict potential.

Id Conflict Policies

The import behavior of packages with conflicting ids can be tweaked with ImportOptions.setIdConflictPolicies(...). For further details refer to its javadoc. The old behavior can be achieved with IdConflictPolicy.FORCE_REMOVE_CONFLICTING_ID.