jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Nuescheler <david.nuesche...@gmail.com>
Subject Re: Getting VersionHistory after removing of a Node
Date Sat, 11 Jun 2005 16:22:45 GMT
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, ...
not just that... 
administrational features such as nodetype registration,  workspace 
management, etc. that definitely deserve an api have purposely been 
removed from the spec to drive schedule and consensus.
jsr-170 is going to be in maintenance mode, so small changes
can still be made, also there will soon be the next version of jcr 
under development in jcp.

> ... but do you think it is possible for an implementation,
> such as JackRabbit, to "extends" the spec by providing such
> functionnalities.
> If so, I certainly volunteer for putting hands in this.
sure, great. as you may see the above mentioned nodetype
registration, workspace mgmt, etc... are already implemented
in jackrabbit, also as a proposal for future jcr development.

> >>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
> type.
> 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
> time.
> 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 :-)
i think cvs proves that having a path based versioning can become
very annoying when you move files. in jcr this is even trickier
since the same node can exist in different workspaces with different
paths at the same time. so when you say "the node is removed"
the question would always be "from which workspace", and is that
significant enough to model it into the the version history.
as far as i remember tobi once had the idea of just modelling
an indication about the path and workspace location(s) into the
version information. i must say given the complexities, it does
not sound as intuitive as one would hope in the beginning.

> 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 !
thank you for the long mail. i also think versioning is very important, 
that's why we pushed the envelope for versioning already in v1.0 of jcr 
to provide the basis for sound config management level versioning.

for me as the spec-lead "industry support", consensus and to allow 
the industry to implement the spec on top of their legacy repositories 
becomes as important as the power of the api itself. 
but i am very happy to receive feedback from users of the api, into 
which direction the future development should go.
...but as i said, jcr v1.0 is a first big step.


View raw message