[
https://issues.apache.org/jira/browse/JCR-1239?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12547089
]
Julian Reschke commented on JCR-1239:
-------------------------------------
> - Is it sufficient if a SPI client calculates the size based on the number of
> Iterator.next() calls?
I don't think so.
> - This will clearly not work for very large collections. Is it required that
> we still want the SPI client to have a way to find out the size?
Yes, I think so.
> - If we need a size information, where does the size belong to?
> - Does it belong to the collection (the parent node) or to the child node
> entries (currently the iterator)?
> - Where is such information usually stored, retrieved from? (examples from
> existing system)
That's hard to tell. Attaching it to the return value of getChildren would have
the benefit to map nicely to what JCR does. Consider SPI2JCR: if the method
resides on the parent node, and a client first calls the new method and *then*
gets the children, how would you avoid calling the JCR getNodes() method twice?
> SPI: Provide possibility to retrieve the number of child-nodes without
> retrieving them.
> ---------------------------------------------------------------------------------------
>
> Key: JCR-1239
> URL: https://issues.apache.org/jira/browse/JCR-1239
> Project: Jackrabbit
> Issue Type: Improvement
> Components: jackrabbit-spi
> Reporter: angela
> Fix For: 1.4
>
>
> separate issue started by julian within issue #1166:
> RepositoryService.getChildInfos is defined to return an Iterator.
> this forces the caller to loop over all entries in order to detect the number
> of child-nodes.
> currently the hierarchy is populated any way, but that could be a source for
> future optimization.
> possible solutions:
> - change return value to RangeIterator
> - change return value to Collection (or Set).
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
