jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marcel Reutegger <marcel.reuteg...@gmx.net>
Subject Re: RowIterator loop is slow?
Date Tue, 05 Dec 2006 15:54:36 GMT
Hi Dan,

thanks for the clarification. I think now I understand.

dan wrote:
> An example of my query scenario would be: 
> For my:document nodes that meet the following query conditions: 
>  1) refer to countries US, or Canada, or Mexico and, 
>  2) refer to sizes Small or Medium, and
>  3) refer to colors Red or Yellow, and
>  4) document content contains arbitrary user entered text
>  5) ... other property based query parameters
> Return the country names referred by above document result (in a unique
> list), and count the number of documents under each returned country name. 
> An example of expected result set may be: 
>    US, 19
>    Canada, 4
> You may have noticed that in query condition 1), users are allowed to
> specify target countries, but the result may not have all country names as
> specified (Mexico here), because other document filtering parameters may
> prevent any "Mexico"-referring document from showing in the result.
> I hope this makes things clear for you. 
> My perception is that I can't achieve the result with One query because
> there no "Select distinct" and "inner join" equivalent in JCR/Jackrabbit.  

and you would also need 'group by' and aggregate functions like sum(). 
enhancements like those are currently discussed in JSR 283.

> Would you have any suggestion/comment on the approach? 

I think the best you can do with the current JCR version is:

1) query for all categories (countries) that match your query. That's the SQL 
query you posted initially but converted into an XPath with an additional 
jcr:deref() at the end to the category node.

2) for each matching category run a new query for that category, which will 
return the documents for that category. Then get the number of documents by 
calling NodeIterator.getSize() instead of looping through all the matches. This 
should be faster that your initial approach.


View raw message