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 Mon, 13 Nov 2006 14:23:07 GMT
(sorry for the late reply - had a customer visit for most of the 
previous week).

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

It will also cause problems when collections are really, really big.

>> 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.

OK, thanks, works for me.

>> 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.

Well, the current design doesn't work for my current back end; and even 
if I *could* change the back end, looking up nodes that have many 
children will still be very expensive.

Does it make sense that I start trying to change JCR2SPI with respect to 

Best regards, Julian

View raw message