jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jan Grathwohl <jan.grathw...@kontrast.de>
Subject Re: NodeIterator drops nodes when sorting
Date Thu, 29 May 2008 14:57:07 GMT
Hi S├ębastien,

"order by @jcr:score" is exactly what I was looking for.

Thank you very much.


Am 28.05.2008 um 20:12 schrieb S├ębastien Launay:

> Hi Jan,
> By setting the JavaBean property respectDocumentOrder to false
> on SearchIndex you can disable document order sorting of query  
> results :
> <SearchIndex  
> class="org.apache.jackrabbit.core.query.lucene.SearchIndex">
>  ...
>  <param name="respectDocumentOrder" value="false"/>
>  ...
> </SearchIndex>
> Indeed, QueryImpl instances will be injected with this property.
> This can also be forced using "order by @jcr:score" in the query.
> But this does not changed the fact that unauthorized nodes will
> not be retrieved from the query and will certainly log warnings
> (from what i have seen AccessDeniedException is not considered
> differently than a RepositoryException).
> Another important behavior is that NodeIterator#getSize()  
> implementation
> may (and will in your case) decrement while iterating over the nodes.
> I think this is needed to get the best performance.
> Jan Grathwohl wrote:
>> Hi,
>> we are having the problem in our application that an XPath query  
>> does not return all results that should be in it. Some debugging  
>> through the Jackrabbit internals showed us that the NodeIterator  
>> from the query result received the right UUIDs from the Lucene  
>> index, but then removed some of them from the list because the  
>> sorting of the results failed.
>> The situation is that we have some nodes in the results list where  
>> not all of the node's ancestors are accessible for the Session  
>> (blocked by our AccessManager). We receive a  
>> DocOrderNodeIteratorImpl from the query that contains these nodes,  
>> and this iterator tries to sort the nodes before the first method  
>> call that accesses them. The comparator then gets an  
>> AccessDeniedException from the getAncestor() of one of the nodes,  
>> and removes these nodes with unaccessable ancestors from the node  
>> list. It also looks like the Comparator directly removes both  
>> compared nodes from the result list if one of them throws an  
>> Exception when being compared.
>> Is this wanted behaviour, that nodes won't be returned by a query  
>> when they cannot be sorted? And is it generally supported in  
>> JackRabbit to have nodes whose ancestors are not accessible?
>> We could work around that by turning off the sorting of the nodes,  
>> we don't need sorted query results here. Is there a way to achieve  
>> this trough JCR or Jackrabbit API? We are currently doing this by  
>> accessing the private  
>> org.apache.jackrabbit.core.query.lucene.QueryImpl object from the  
>> query result through Java reflection, and then calling a  
>> setRespectDocumentOrder(false) on it. But maybe there is a nicer  
>> way (as probably almost any way would be nicer) to achieve the  
>> same result?
>> I will attach the XPath query and Exception stack trace from our  
>> log file.
>> Best regards and Thanks,
>> Jan
>> 15:55:53,194 DEBUG [tcmdataaccess] QueryString is: //element(*,  
>> tcs:category) [fn:lower-case(@tcs:defaultContentType) =  
>> 'information'] /element(*, tcs:categorylocalization)  
>> [ @tcs:locview = 'pngo' and @tcs:loclanguage = 'de']
>> 15:56:41,836 ERROR [DocOrderNodeIteratorImpl] Exception while  
>> sorting nodes in document order: javax.jcr.AccessDeniedException:  
>> cannot read item 827cae10-ad2e-44ad-927f-a65e96e0d4f2
>> javax.jcr.AccessDeniedException: cannot read item 827cae10- 
>> ad2e-44ad-927f-a65e96e0d4f2
>>     at org.apache.jackrabbit.core.ItemManager.getItem 
>> (ItemManager.java:392)
>>     at org.apache.jackrabbit.core.ItemManager.getNode 
>> (ItemManager.java:350)
>>     at org.apache.jackrabbit.core.ItemImpl.getAncestor 
>> (ItemImpl.java:1403)
>>     at  
>> org.apache.jackrabbit.core.query.lucene.DocOrderNodeIteratorImpl 
>> $1.compare(DocOrderNodeIteratorImpl.java:220)
>>     at java.util.Arrays.mergeSort(Arrays.java:1284)
>>     at java.util.Arrays.mergeSort(Arrays.java:1295)
>>     at java.util.Arrays.sort(Arrays.java:1223)
>>     at  
>> org.apache.jackrabbit.core.query.lucene.DocOrderNodeIteratorImpl.init 
>> OrderedIterator(DocOrderNodeIteratorImpl.java:172)
>>     at  
>> org.apache.jackrabbit.core.query.lucene.DocOrderNodeIteratorImpl.hasN 
>> ext(DocOrderNodeIteratorImpl.java:131)
>>     at  
>> kontrast.toshiba.datastore.accessimpl.content.search.ContentSearchImp 
>> l.getContentList(ContentSearchImpl.java:267)
>>     at  
>> kontrast.toshiba.datastore.accessimpl.content.search.ContentSearchImp 
>> l.findContents(ContentSearchImpl.java:187)
>>     at  
>> kontrast.toshiba.datastore.accessimpl.content.search.ContentSearchImp 
>> l.performQuery(ContentSearchImpl.java:117)
>>     at  
>> kontrast.toshiba.datastore.accessimpl.content.search.ContentSearchImp 
>> l.getResults(ContentSearchImpl.java:89)

View raw message