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: debugging a query that returns no results
Date Fri, 28 Mar 2008 10:42:48 GMT
Hi Dave,

Dave Brosius wrote:
>    When i do a search with a query string such as
> //*[@jcr:primaryType = 'prm:File' and jcr:contains(@prm:Title, 
> '"lazy"')] order by jcr:score() descending
> it works as i expect. When however i limit the sub tree like
> /prm:Projects/prm:Project3781/prm:Documents//*[@jcr:primaryType = 
> 'prm:File' and jcr:contains(@prm:Title, '"lazy"')] order by jcr:score() 
> descending
> where the /prm:Projects/prm:Project3781/prm:Documents part is retrieved 
> from a call to node.getPath()
> nothing is returned

you forgot to prefix the statement with /jcr:root.

from the spec:

The context node of an XPath query is the XML node relative to which the query 
expression is evaluated.

A relative XPath statement (one that does not have a leading /) will be 
interpreted relative to the root node of the workspace, which, in the XML 
document view is the top-most XML element, <jcr:root>. This means that one 
should not include jcr:root as the first segment in a relative XPath statement, 
since that element is already the default context node.

An absolute XPath (one with a leading /), in contrast, will be interpreted 
relative to a position one level above <jcr:root>. This means that an absolute 
XPath must either begin with // or with /jcr:root in order to match anything at all.

> I've walked thru the code till i get to the lucene execute query, at 
> which point i don't have source.

what sources are you missing exactly? all code should be available in source form.

> As a general question, are there any tips for figuring out why a search 
> is returning no results

unfortunately jackrabbit has very poor support for analyzing query execution. It 
currently boils down to debugging java code.

debug messages about node sets at different states of the query would probably 
be a first easy step to improve the situation. I've filed a jira issue: JCR-1507.


View raw message