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 caching, was: [jira] Resolved: (JCR-1361) Lock test assumes that changes in one session are immediately visible in different session
Date Fri, 08 Feb 2008 13:53:20 GMT
Marcel Reutegger wrote:
>> How would JCR2SPI that *all* children have been returned?
> good question! I don't know. I'm not that familiar anymore with the 
> jcr2spi code. I remember a discussion with angela about a flag, which 
> indicates that child node entries are complete. But I guess we never 
> implemented this.


But it's good that we finally agree that there's an unresolved issue 
here :-)-

> I think your question reveals a design flaw in the batch read method 
> RepositoryService.getItemInfos(). And it's not just about knowing all 
> children, it's also about the order of nodes. Even if we are sure we got 
> all children we still have to call getChildInfos() in case the parent 
> supports orderable child nodes. Angela, please correct me, if I'm way 
> off here...

Couldn't we just require that for orderable child nodes, their ItemInfos 
are returned in order?

> Hmmm, does that mean a batch read should also be allowed to return 
> ChildInfo, with the restriction that it must be complete, when sent?

That would be less expensive than returning ItemInfos for the children. 
But would it be useful?

>> And how should the SPI implementation know that somebody *wants* to 
>> retrieve all children?
> I'm not sure I understand your question, because there is 
> RepositoryService.getChildInfos(). Do you mean something else?

I was thinking in terms of PROPFIND Depth 0/1, where 1 includes 0. That 
is, it's possible to return information about the node and all it's 
children, saving yet another round trip. Which may not be sufficient 

But returning ChildInfos will not be sufficient here, because there is 
no Batch aspect built in; thus, JCR2SPI still needs to fetch the 
ItemInfos for each child node in a separate call.

BR, Julian

View raw message