Julian Reschke wrote:
Julian Reschke schrieb:
...
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...

the current design of the spi demands that the client on top of the spi resolves paths to ids and vice versa. this design was actually just borrowed from the jackrabbit implementation, where the lower layers don't know about paths but the items just have forward and backward references (parent uuid, child node entries and property names).

I'm not so sure if we should move this task to the server. I think in most cases a workspace is accessed in a traversal way. At least that's what most methods in the JCR are about. To get a node or a property you usually start from a node you accessed before.

But you are right that this design will cause problems when there are ancestor nodes that cannot be accessed.

in the meantime I realized that the IdFactory can do that for me, assuming it allows

  .createNodeId((NodeId)null, path);

...where path would be absolute -- which the one in spi2dav doesn't (why?). (As a matter of fact a createNodeId(Path) signature would be useful).

the method createNodeId(NodeId, Path) is meant for ids that are relative to an existing id. createNodeId(String, Path) is what you are looking for. here, the String uuid parameter is optional.

So given the fact that the SPI API at least in theory has the capability to do the lookup without having to access the parent collections, shouldn't JCR2SPI use that when circumstances require that?

major parts of the jcr2spi currently rely on hierarchical caching structure of nodes and properties. which means if an item is in the cache it's ancestors are cached as well. this simplified the handling of spi ids a lot because in some cases they can be very volatile. think of same name siblings and parent nodes that become referenceable.

regards
 marcel

Reply via email to