Marcel,
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 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."
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.
OK.
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.
Yes.
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
