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: more on scores
Date Fri, 16 Feb 2007 13:32:26 GMT
Paco Avila wrote:
> This is the "okm:resource" definition:
> 	[okm:resource] > nt:resource, mix:versionable
> 	- okm:size (long) mandatory
> 	- okm:author (string) mandatory
> This two queries returns the same results in the same order but the
> scores are higher in the second:
> 	//element(*,nt:resource)/@jcr:path[jcr:contains(.,'apache')] order by
> @jcr:score descending
> 	//element(*,okm:resource)/@jcr:path[jcr:contains(.,'apache')] order by
> @jcr:score descending
> Why the scores are not equel if they refers to the same indexed data?

because the query is not the same. scoring in jackrabbit (in the end it's 
lucene) not just depends on the jcr:contains() function in your query but also 
all other parts.

element(*, nt:resource) is roughly translated into:
@jcr:primaryType = nt:resource OR @jcr:primaryType = okm:resource

whereas element(*, okm:resource) is translated into:
@jcr:primaryType = okm:resource

The second condition therefore provides a better match (from a scoring 
perspective) because it is more specific.

As for the first condition, one part of the expression (@jcr:primaryType = 
nt:resource) will always evaluate to false and drag down the score.


View raw message