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.
regards
marcel
