[
https://issues.apache.org/jira/browse/JCR-1166?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12544864
]
angela commented on JCR-1166:
-----------------------------
i would suggest modify the LazyItemIterator to apply the same logic as present
currently in the query.NodeIteratorImpl:
- take the size of original collection as estimation for the number of Items
available during iteration.
- recalculated the size if entries that cannot be resolved to Items are found
during the iteration.
this would have the following benefits:
- if nothing changes in the meantime the size estimate is accurate
- no extra effort to calculate the size upon/before creating the iterator
- don't modify lazy behaviour of the iterator
drawback:
- size may shrink during iteration.
> JCR2SPI does not provide actual size on RangeIterator.getSize()
> ---------------------------------------------------------------
>
> Key: JCR-1166
> URL: https://issues.apache.org/jira/browse/JCR-1166
> Project: Jackrabbit
> Issue Type: Improvement
> Components: jackrabbit-jcr2spi
> Reporter: Julian Reschke
> Priority: Minor
>
> Currently, JCR2SPI always returns -1 on RangeIterator.getSize().
> This return value is legal (meaning "unknown"), but may cause clients to
> simply iterate through the whole list when what they really want is simply
> the count.
> Use case:
> "The use case is to count the number of members of a NT_FOLDER without having
> to open up the NT_FOLDER and count all the members (and I assume load them
> into memory) "
> To make this happen we probably need to move away from simple Iterators on
> the SPI level, and put quite some additional work into JCR2SPI.
> Feedback appreciated.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
