jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ard Schrijvers" <a.schrijv...@hippo.nl>
Subject RE: Total size of a query result and setLimit()
Date Fri, 17 Aug 2007 08:00:50 GMT
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
> 
> 

Mime
View raw message