[
https://issues.apache.org/jira/browse/JCR-3402?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jukka Zitting updated JCR-3402:
-------------------------------
Fix Version/s: (was: 2.5.3)
I'm hesitant to apply the patch as is for the following two reasons:
* AFAICT the numResults calculation in the patch should not include the {{+
(int) offset}} term. The offset is added higher up in the code when skipping
first few results, but it probably shouldn't be included in the numResults
count.
* More seriously, I'm not very happy with the way the getSize() method could
currently be used to circumvent read access controls. Making the method return
fewer -1 results will make that issue more pressing. See the FIXME comment in
getTotalSize(). Thus, I'd rather see us abandon the underlying Lucene result
size entirely as a component in calculating the getSize() return value. Instead
we could simply prefetch up to some N result nodes, have getSize() return the
count if there are fewer than N results and -1 if more.
> getSize() returning too many often -1
> -------------------------------------
>
> Key: JCR-3402
> URL: https://issues.apache.org/jira/browse/JCR-3402
> Project: Jackrabbit Content Repository
> Issue Type: Improvement
> Reporter: Cédric Damioli
> Attachments: QueryResultImpl.java.patch
>
>
> I've came accross the well known behaviour of query results returning -1 when
> asked for getSize().
> While this is ok for optimization reasons (lazy results fetching), I just
> discovered that the default "resultFetchSize" value in lucene queries is
> Integer.MAX_VALUE, so in all queries I've ever executed, all results were
> actually fetched before asking for getSize, so IMHO nothing prevents
> getSize() to return the real value instead -1
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
