On Sat, Oct 26, 2013 at 10:44 PM, Jukka Zitting <[email protected]> wrote: > Hi, > > On Fri, Oct 25, 2013 at 12:24 AM, Torgeir Veimo <[email protected]> > wrote: >> Furthermore it seems it happens when query limit <= result size. If I >> set limit to one higher than the size of the result set, it correctly >> gives the correct size. > > The reason for this behavior is that when you set the limit on the > query Jackrabbit will stop counting when the limit is reached, and > thus it won't know what the total number of results without the limit > would be. The reason why it worked before JCR-3402 is that we used a > guess based on the raw number of Lucene matches without considering
IIRC, the #getSize() method worked a bit different Jukka. #getSize() on queries *with* an order by clause *and* a limit would at most give 'limit' as the size. Even if there where, say, 1.000 hits, the #getSize() used to return only 10 in case a limit of 10 was set. For this reason, through Hippo Repository, we also expose a 'raw' (unauthorized) total size, which is just the result size from Lucene (and since we integrated authorization into the queries we have cheap correct total counts) Any way, imo it has always been quite confusing, but changing the confusing behavior in a micro version doesn't help. I saw the JCR-3402 some time ago. I expect the Cédric Damioli in his environment did not use a limit on queries *and* had a default resultFetchSize of Integer max value. Hence, under his circumstances, it might have seem like a good improvement. OTOH, I haev to admit I am a bit second guessing as I did not investigate it well enough Regards Ard > things like read access controls, which is a potential security issue > as it could result in read-protected information leaking through the > query system. > > BR, > > Jukka Zitting -- Amsterdam - Oosteinde 11, 1017 WT Amsterdam Boston - 1 Broadway, Cambridge, MA 02142 US +1 877 414 4776 (toll free) Europe +31(0)20 522 4466 www.onehippo.com
