[
https://issues.apache.org/jira/browse/JCR-1166?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12545021
]
angela commented on JCR-1166:
-----------------------------
noe... you get the size immediately. but it may not be totally accurate if
nodes are removed after accessing
the iterator (or if nodes are removed by somebody else and cachebehaviour is
observation or if you refresh
the session after accessing the iterator).
in any case: if during iteration an invalid/removed item is encountered the
effective size will be lower.
that may happen in any case.
that's an built in consequence of the lazy iteration and not an effect of
whatever size-value detection.
the only thing that changes: initially i thought that -1 would be more
appropriate than a size value that is
not 100% correct.
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.
