jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Julian Reschke <julian.resc...@gmx.de>
Subject Re: SPI: ItemInfo.getParentId()
Date Fri, 03 Nov 2006 13:23:28 GMT
Marcel Reutegger schrieb:
> 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.

Understood. For the record: in a previous project where we exposed 
version histories in the namespace we choose a similar approach.

>> 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...

Right. I don't have an API for that.

>> 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'd rephrase that slightly as "the spec ignores the issue" :-). JCR 
clients already have to deal with child nodes not showing up in the 
parent collection, for instance due to permission problems.

>> I think requiring this makes many use cases extremely hard, if not 
>> impossible, to implement.
> what use cases do you have in mind?

Well, this one for instance.

Another one would be where the system exposes all referenceable nodes 
with a second path, consisting of a collection ("/jcr:flat/") plus the 
UUID. That's an approach I've seen in use to provide users with an 
alternate, stable, identifier. The common pattern here is that the nodes 
exposed at a certain part of the namespace are just projections from 
somewhere else, and not something that is persisted under that name.

Back in September, I claimed that implementing simple versioning was 
trivial, maybe I now have to take that back ;-)

Best regards, Julian

View raw message