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 12:09:17 GMT

thanks for the feedback.

> Hi Julian,
> Julian Reschke wrote:
>> here's a question on ItemInfo.getParentId().
>> In my store, all version histories live directly below 
>> /jcr:system/jcr:versionStorage. However, getNodeIds() will not return 
>> any children. As far as I understand, that is legal in JCR (versioning 
>> nodes are exposed below jcr:versionStorage, but you can't navigate to 
>> them).
> Looking at the relevant sections in the spec, I think the version 
> storage should behave just like any other tree in the workspace:
> section
> "Exposing the version storage as content in the workspace allows
> the stored versions and their associated version meta-data to be
> searched or traversed just like any other part of the workspace."

Yes, that's what JCR says, agreed.

In practice I remember lots of conversations about version storage in 
which I think it was assumed that just because you expose a node, it 
doesn't need to appear as a child of it's parent (whether by returning 
an empty list or throwing an Exception would be a separate issue).

We may have to take this to the JCR mailing list for clarification. My 
assumption was that it's perfectly ok to - for instance - expose all 
version nodes with local name == UUID within one parent folder, and of 
course that folder wouldn't be able to enumerate all children.

>> With this setup, I'm getting an NPE (see below), as the code seems to 
>> rely on the assumption that if getParentId() returns something != 
>> null, the item will show up in the child node list of the parent.
> A parent child relation must always resolve. Unless its the root node, 
> then obviously there is no parent.


>> I can workaround this by return null in this special case for now, but 
>> I'd really like to clarify
> Hmm, that should be reserved for the root node. The jcr2spi layer will 
> probably get confused later when it has to deal with multiple nodes 
> without a parent. I'm actually not sure what the exact behaviour in that 
> case is right now.
>> - whether the setup itself is ok, and
> 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?).

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

>> - what getParentId() is supposed to return in this case...
> well, as mentioned already, every parent id must resolve to a child node 
> entry in the parent.
> hmm, the more I think about it, we might have to deal with this issue at 
> other occasions. It may happen that a node is returned by a query that 
> has never been requested, but its parent node has. assuming that the 
> jcr2spi layer still has the old version of the parent node it will not 
> see the new child node entry in there for the node returned in the query.


> While the jcr2spi layer is technically able to just add the new child 
> node entry, it can be difficult to determine the exact sort order of the 
> new child node in case the parent node supports orderable child nodes.
> To get back to the initial problem, I think from a specification 
> standpoint the version storage must be traversable and expose all 
> version histories. That would certainly solve your issue with the 
> current state of the jcr2spi layer.

I think that's indeed a specification issue. Can a client always rely on 
  a node's ability to enumerate all children? I think requiring this 
makes many use cases extremely hard, if not impossible, to implement.

Independently of that, I think it would be good if SPI itself would not 
impose that constraint.

Best regards, Julian

View raw message