Hi Julian,
Julian Reschke wrote:
How about using an intermediate structure like jackrabbit does and
expose the version histories that way?
I have to confess that I'm not sure how it currently does that (pointer?).
jackrabbit uses the 6 highest digits of the uuid of the versionable node to
construct an intermediate structure to the version history of that node. the
label of the version history node is the full uuid of the versionable node.
The trouble is that in the system I currently have I can't enumerate
version histories *at all* (well, except by looking at every single node
in the system and asking it for it's version history).
can you at least search for version history uuids with a certain pattern? That
would allow you to group your version histories in a sub node structure under
jcr:versionStorage. But I guess when you say you can't enumerate them at all,
that means it *is* impossible...
I think that's indeed a specification issue. Can a client always rely on
a node's ability to enumerate all children?
well, according to the spec it can...
I think requiring this
makes many use cases extremely hard, if not impossible, to implement.
what use cases do you have in mind?
regards
marcel
