Hi Sébastien,
"order by @jcr:score" is exactly what I was looking for.
Thank you very much.
Jan
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)
