Thank you, that worked.
If I understand then, if a query comes in starting with / and not with
/jcr:root it is always an error.
Perhaps a check could be added to the query parser to throw an exception in
this case.
but thanks again.
dave
----- Original Message -----
From: "Marcel Reutegger" <[EMAIL PROTECTED]>
To: <[email protected]>
Sent: Friday, March 28, 2008 5:42 AM
Subject: Re: debugging a query that returns no results
Hi Dave,
Dave Brosius wrote:
When i do a search with a query string such as
//[EMAIL PROTECTED]: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//[EMAIL PROTECTED]: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:
<quote>
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.
</quote>
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.
regards
marcel
