You have to first delete the node and then its versions.
For this you need to store the version history before deleting the node.
Indeed, if you delete the node you cannot access the version history
anymore.
Here an example, from JCR-134 test case:
Node n = rootNode.addNode("test");
n.addMixin(mixVersionable);
rootNode.save();
VersionHistory vh = n.getVersionHistory();
// From here there is the dumy root version
// and the base version references this root version
// First version which will be the new base version
Version v10 = n.checkin();
n.checkout();
// Second version which will be the new base version
Version v11 = n.checkin();
n.checkout();
// Remove node
n.remove();
rootNode.save();
// Remove the first version
vh.removeVersion(v10.getName());
// Remove the second
vh.removeVersion(v11.getName());
// vh still exists and it contains the empty
// and its immutable dummy root version
how can I restore some information about a node after it being deleted? how
i get a reference for your version history?
You can query nt:versionHistory or nt:version nodes into
/jcr:system//jcr:versionStorage//* branch.
--
Sébastien Launay
Diego Marin Santos wrote:
well... do you manage to remove the base version?
The root *version* has the uuid of the base *version* as its successor and
the base *version* has the uuid of the root *version* as its predecessor.
Since a reference is existing i am unable to delete each of them and it
gives me a Referential Integrity Exception.
2009/1/5 Sébastien Launay <[email protected]>
Hi,
IMO if one deletes a node and its belonging versions, it's
because he does not want to (and cannot) retrieve this node later.
i agree with you
One of my company clients has the following use case:
- version a content because we want to restore it to a previous version
and to show its history
- about 2000 contents of this kind is created every week
- after 6 months we purged the content, among other things
the node history (to keep only the root version and the base version)
- after 3 years we deleted the content (the node and then its remaining
versions)
Because, the node is deleted but its empty version history is still
present in Jackrabbit storage, the disk usage continues to grow.
The goal of the purge was precisely to have a constant disk usage
because the content creation throughput is constant (i.e. after 3
years of production the number of nodes must have reached a
maximum).
I have created a (first-try) patch for fixing this issue which still
awaits feedback ;) :
http://issues.apache.org/jira/browse/JCR-134
--
Sébastien Launay
Tako Schotanus wrote:
IMO this is because versioning is not seen as a method to go back to older
version for isolated files but as a way to get a "snapshot" of the state
of
your entire workspace. If at some point you decide that you don't like the
changes that have been made to your repository and would like to go back
to
the state it was in yesterday it would be very inconvenient if it would be
impossible to recuperate the deleted information that existed yesterday.
I understand the need to "physically" delete information, for example to
free up the space it uses, but it should be an exceptional operation
instead
of the norm and has nothing to do with versioning.
On Mon, Jan 5, 2009 at 19:19, Diego Marin Santos <[email protected]
wrote:
I've read on internet a jackrabbit user saying the following:
"*AFAIK the version storage was not intended to be removed completely by
**
the JCR spec, since one idea of versioning is to be able to recover
deleted nodes. That's why it's not entirely possible to delete all
things inside the versioning storage (let's say this use case was not
**considered*)."
I don't agree because in my opinion versioning makes sense when we wanna
modify a file and may wanna restore the previous file versions in the
future.
When we delete a file, we don't think of restoring previous file
versions.
Moreover, deleting a node(representing a file) we won't get a reference
for
your version history, then why should we keep the version history of this
node?
