[
https://issues.apache.org/jira/browse/JCR-1166?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12545873
]
angela commented on JCR-1166:
-----------------------------
for the record (translation of oral communication):
the problem julian is referring to is 2-folded:
1) the -1 return value of the RangeIterator implementation.
2) the fact that RepositoryService.getChildInfos returns an Iterator -> thus
the caller needs to iterate in order to
detect the size. That could be improved thus making not only the
ItemIterator lazy but also the code that
populates the hierarchy.
Let's put 2) to a separate SPI issue. vale?
If nobody object i'm going to solve this issue as suggested.
angela
> 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
> Assignee: angela
> Priority: Minor
> Fix For: 1.4
>
> Attachments: JCR-1166.patch
>
>
> 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.
