jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marcel Reutegger <marcel.reuteg...@gmx.net>
Subject Re: SPI: ItemInfo.getParentId()
Date Fri, 03 Nov 2006 10:00:15 GMT
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:


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

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

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


View raw message