Julian Reschke wrote:
Marcel Reutegger wrote:
David Rauschenbach wrote:
My main problem with SPI is that if I return depth=1 results from
getItemInfos (a NodeInfo for each subfolder), JCR2SPI ends up
subsequently
calling getChildInfos anyway, to find out what ALL the children are,
regardless of the fact that I just returned what all the children are
in my
GetItemInfos response.
this is because jackrabbit-jcr2spi did not have a cache. angela
recently committed the changes discussed in JCR-1011. this introduces
a cache and should avoid the calls for the children if they were
delivered in a previous call.
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.
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...
Hmmm, does that mean a batch read should also be allowed to return ChildInfo,
with the restriction that it must be complete, when sent?
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?
regards
marcel
