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: [jira] Commented: (JCR-1405) SPI: Introduce NodeInfo.getChildInfos()
Date Mon, 25 Feb 2008 09:45:28 GMT
Michael Dürig wrote:
> I think the idea of adding getChildInfos to NodeInfo was to cut down on
> individual calls to the SPI. In a call to getItemInfos an implementation
> may choose to return any number of ItemInfos in one single batch. By

The problem, as far as I understand, is that the saving is in the wrong 
place; at least for the use case I am trying to optimize and which 
started this thread.

For enumerating the children of a collection, the call removes a single 
NodeId->NodeInfo resolution for the container.

The overhead for iterating through the children (resolving ChildInfos zo 
NodeInfos) is unchanged. Or am I missing something?

> making the ChildInfos directly available for those nodes having its
> child nodes in the batch, no further calls to the SPI are needed.

Returning ItemInfos in a batch is not going to happen for the children 
of a large collection. After all, the SPI impl has no idea whether the 
caller wants to see them.

> Furthermore by doing so an SPI implementation can decide on how much
> information it want to read from a back-end store in a single sweep and
> delegate caching to the upper jcr2spi layer.

That's all understood and nice, but it doesn't help *at all* for the 
problem I'm trying to solve.

BR, Julian

View raw message