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 14:50:50 GMT
Marcel Reutegger schrieb:
> ...
> 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.
> ...

I can resolve my original problem with the change below...:

--- 
src/main/java/org/apache/jackrabbit/jcr2spi/state/WorkspaceItemStateFactory.java 
26 Oct 2006 12:20:08 -0000	1.2
+++ 
src/main/java/org/apache/jackrabbit/jcr2spi/state/WorkspaceItemStateFactory.java 
3 Nov 2006 14:18:50 -0000
@@ -96,7 +96,8 @@
              NodeState parent = (parentId != null) ? (NodeState) 
ism.getItemState(parentId) : null;

              if (parent != null) {
-                return parent.getChildNodeEntry(info.getQName(), 
info.getIndex()).getNodeState();
+                ChildNodeEntry child = 
parent.getChildNodeEntry(info.getQName(), info.getIndex());
+                return child != null ? child.getNodeState() : 
createNodeState(info, parent);
              } else {
                  return createNodeState(info, parent);
              }

...however once I do that - as expected - other problems surface.

Looking at JCR2SPIs NodeImpl and HierarchyManagerImpl it seems that the 
only way to access a Node by absolute path is to recursively access all 
parent nodes, visiting their children.

This seems to be not only inefficient, but may also cause a problem when 
  the given user doesn't have read access to all parent nodes...

Shouldn't we have something like:

   NodeId RepositoryService.getNodeId(QPath path);

Best regards, Julian

Mime
View raw message