jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sébastien Launay <sebastien.lau...@anyware-tech.com>
Subject Re: Deleting the version history of a node
Date Mon, 05 Jan 2009 21:19:33 GMT
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 <sebastien.launay@anyware-tech.com>
>
>   
>> 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 <diegomrsantos@gmail.com
>>>       
>>>> 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?
>>>>
>>>>
>>>>
>>>>         
>>>
>>>       
>>     
>
>   


Mime
View raw message