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 8.2.2.2:
"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.
regards
marcel
