jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Angela Schreiber <anch...@day.com>
Subject Re: JCR to SPI performance improvment
Date Thu, 06 Aug 2009 10:32:46 GMT
sorel wrote:
> Thanks for the answer,
> I'm not sure to understand what you mean.
> Do you suggest that I load all childs when the getItemInfos() is made ?

you don't have to load all the children. getItemInfos may return
an arbitrary amount of itemInfos. you may even apply your specific
logic... example: if a file is loaded the complete subtree is
shipped, while for a folder you may decide that only the next N
levels are of interest... or only child nodes having a particular
node type or name pattern...

you may add your own logic regarding the behaviour of getItemInfos
depending on your content structure, the needs of your api users
etc. etc...

in contrast:
NodeInfo.getChildInfos will be used by jcr2spi to determine if
the complete set of children has been loaded or not.
NodeInfo.getPropertyIds must always list the ids of all existing
props (whether the properties themselves are immediately loaded or
not is again defined by the getItemInfos).

that way getItemInfos can be implemented to minimize the
number of roundtrips needed... that may vary from implementation
to implementation and from use case to use case.

hope that helps

> I've made a quick test, I see that he iterate on all items given by the 
> getItemInfos() before iterating
> over the childs iterator.
> this is not a solution since It might contain an undefined number of sub 
> nodes.
> I believe there is a kind of cache in the "hierarchy", I my case (and I 
> believe in many cases)
> the cache won't be able to hold all nodes, this will only result in some 
> useless loading.
> johann
> Michael Dürig a écrit :
>>> An instanceof test on the childInfo object to see if it's already a 
>>> nodeInfo could
>>> avoid the call to getNodeInfo (and all name resolver operations, path 
>>> parsing and so on).
>> Johann,
>> While this approach might work, the preferred way to achieve this kind 
>> of batch reading is to implement RepositoryService.getItemInfos(). 
>> Here you can return arbitrary ItemInfos in a single batch. The jcr2spi 
>> module will then put these into the hirarchy without additional calls 
>> to the spi layer. See also https://issues.apache.org/jira/browse/JCR-1797
>> Michael

View raw message