Section 15.8 of the JSR-283 specification covers removal of specific versions within a version history. However, I'm unable to find any information in the spec about removing entire version histories. There certainly may be regulatory and policy reasons for preventing the removal of some data, but likewise there may be regulatory and policy reasons for removing all store data relating to some particular topic. IMO, a repository implementation can provide the tools to allow both, but cannot choose one specific behavior. We have to allow applications to implement their own policies and behavior, and thus it needs to be addressed in the specification and possible API if there are changes to JavaDoc and/or interfaces.
The other problem with removing only the versions is that it is likely that the root version remain. Thus, when frequently creating, modifying and removing versionable nodes, the amount of version history storage will continue to increase and cannot be compacted (at least through activities instigated by standard API calls).
So I think there are a couple of issues.
- Once a node is removed, it is not possible to find the version history. That's because the VersionManager.getVersionHistory(...) takes the path of the versionable node. Thus a client can only find a version history for a removed node only if it somehow remembers the path. Plus, I would suspect that most implementations do not store version histories based upon the path, but rather the identifier. Should we change the JavaDoc on method to explicitly say identifier paths are accepted, or should we add VersionManager.getVersionHistoryById(String versionableId)? (Yes, a client still needs to know the identifier, but at least that is durable.)
- Removing version histories is complicated by the fact that multiple workspaces may have corresponding versionable nodes. Thus, removal of a versionable node from one workspace does not mean the version history is no longer used. However, if no other workspace has a corresponding versionable node, then it should be possible to completely remove a version history. Currently the TCK tests check that this is not permitted, because it checks that Item.remove() does not work on a VersionHistory node. Considering that the spec defines an explicit way to remove Version nodes (rather than allow Item.remove() to work), we should add a VersionManager.removeVersionHistory(String path) (and based on #1 above perhaps also a VersionManager.removeVersionHistoryById(String versionableId. These methods should fail if there is a versionable node with that identifier in at least one workspace.
- What happens to the version history when a versionable node is made to be no longer be versionable? For example, if a node is versionable only because it explicitly has "mix:versionable" in the list of mixin types, what happens when "mix:versionable" is removed from the node (assuming the version history was already created prior to this)? Is the version history even valid anymore? Can an older version be restored to a node that is no longer versionable? (If not, then we need to clarify this in the section that talks about restoring.)
- *Does it make sense to add "Node.remove(boolean removeVersionHistories)", so that a subgraph (of 1 or more potentially versionable nodes) can be removed and their version histories be removed at the same time (assuming the version histories can be removed because there are no corresponding nodes in other workspaces)?