Hello, > Christoph Kiehl wrote: > Hi, > > while fixing a little bug in rev 566778 I became aware that > there is no > possibility to retrieve the total result size of a query > anymore if setLimit() > is used. But I need that information and I think I'm not > alone.
Indeed, obviously for simple things like paging you need the total number > The question is > how to implement this? Should this maybe even be covered by > jsr 283? The method > could be either implemented on the LazyScoreNodeIterator > (RangeIterator) but may > be it is more appropriate for > LazyQueryResultImpl/QueryResultImpl (QueryResult) > because limits are specific to querying. WDYT? Beside where to implement it, how can it be implemented efficiently? IIUC, the only 'fast' total result size of a query is the total hits in lucene. But these lucene hits might contain removed nodes (isn't?) and, even harder, if people hook in there own accessMgr, you certainly do not know how many hits a user is allowed to see in total without doing the iteration over all lucene hits, which brings you back to the slow situation before https://issues.apache.org/jira/browse/JCR-989. In previous applications, I used to use the lucene hits count for efficient paging for users that have a 'read all' access, and I used to take paging only with 'next' when paging through hits for users which can only read certain parts of the repository/workspace. IMHO, it becomes very hard (if possible at all) when you need the total number of hits in a performant way when ACLs are involved. But, I think a total result size is indeed indispensable. It might be sensible to have a 'lucene hits size' and a 'granted/real hits size', where the second might obviously become very slow (also depending on your used accessMgr), and possibly log to the proposed performance log channel [http://issues.apache.org/jira/browse/JCR-1062] with a warning Regards Ard > > Cheers, > Christoph > >
