Re: SPI caching, was: [jira] Resolved: (JCR-1361) Lock test assumes that changes in one session are immediately visible in different session

[Julian Reschke]

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.

Yup.

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

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