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 Mon, 06 Nov 2006 09:41:36 GMT
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.


View raw message