jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Cédric Damioli <cedric.dami...@anyware-tech.com>
Subject Re: Getting VersionHistory after removing of a Node
Date Sat, 11 Jun 2005 15:09:56 GMT

David Nuescheler a écrit :

>hi cedric,
>>1) Is there a way to also remove the VersionHistory (there is an API to
>>remove each Version, but not the rootVersion nor the VersionHistory
>>itself) ?
>true.. we even had discussion in the expert group around the feature 
>of removing versions. it seems that the removal of version 
>histories and versions is more of administrational cleanup process in the
>repository than something that an application should have to worry about.
>but i think i can see your point and if we shoose to extend jcr into the
>repository administration realm this may certainly be a relevant addition.
I have a classical application where an administrator manages releases 
of documents.
He may want to purge intermediate work versions of documents between 
each release (VersionGistory.removeVersion() is perfect for that), but 
also delete a document *and all its past revisions*, due to some legal 
requirements. For this last point, it seems JCR lacks a few 
functionnalities, as you also point out.
With this simple exemple in mind, it seems that managing removal of 
versions and version histories is not only the concern of the 
repository, but may also be the concern of a certain business logic.
The spec is now final, so there is no chance to see some enhancements in 
the next months, but do you think it is possible for an implementation, 
such as JackRabbit, to "extends" the spec by providing such 
If so, I certainly volunteer for putting hands in this.

>>2) How can I have access to VersionHistory, once the Node is deleted ?
>>The JCR API contains a paragraph about "Searching and Traversing version
>>storage" with queries, but this won't help me to get the VersionHistory
>>of a deleted Node, or am I missing something ?
>what would you like use to identify the "deleted node"? uuid? path? path
>& workspace? path & workspace & date? other properties?
>currently we assumed the uuid (or other properties) as the identifier, but 
>i think there is a bit of a grey area there, so i would be interested to hear 
>your usecase.
My use case is to identify nodes by both path and primary type, and I 
want to retrieve deleted nodes by name (path) and/or date and/or primary 
I actually have in mind the behaviour of a CVS repository, in particular 
the special "Attic" repository, which stores the deleted content.
When you try to access to an old version of a file (through its path), 
the CVS server also have a look in this directory, so it can serves old 
files by date, revision, tag, ...
A CVS server does not even actually "deletes" files, it just change 
their status to "dead" and move them in the Attic directory.
Of course, I can implement the same behaviour by hands on top af a JCR 
repository : flag the node with a status property, indicating if the 
content represented by the node is alive or not.
But in this case, no nodes will ever be deleted, and the repository 
won't stop growing, and furthermore it seems to me that JCR and its 
implementations are capable of much more :-)

I don't have precise solutions in mind, only a few tracks :
I know that the spec is based on UUID for all versioning concerns, but 
maybe the VersionHistory can hold the last known path of the Node before 
deletion. Or maybe each Version can hold the path of the Node at checkin 
For date-based search, things are easier as each Version knows its 
creation time. Maybe the VersionHistory only miss a 
getVersionByDate(Calendar) method ?
For primary-type based search, I can't understand why the 
jcr:frozenPrimaryType is only held by each jcr:frozenNode and not only 
once by the VersionHistory, as I think that the primary type of a given 
Node cannot change during its whole life. But I may miss something here.

And the last point is the lookup of the VersionHistory of a given 
deleted Node : having to use the QueryManager to find it is a bit 
tedious. But here, I can't find a better solution. I'm out of ideas for 
today :-)

Sorry for this long mail, but I think versioning capabilities are a key 
feature of JCR, and I would like to see them as powerful as possible !

BTW, many thanks to JCR people and to the Jackrabbit community for these 
wonderful toys ;-p

Best regards,

View raw message