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
