jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Marcel Reutegger (JIRA)" <j...@apache.org>
Subject [jira] Updated: (JCR-2759) Collapse nested OR expressions
Date Tue, 28 Sep 2010 08:55:34 GMT

     [ https://issues.apache.org/jira/browse/JCR-2759?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel

Marcel Reutegger updated JCR-2759:

    Attachment: JCR-2759.patch

Proposed patch.

> Collapse nested OR expressions
> ------------------------------
>                 Key: JCR-2759
>                 URL: https://issues.apache.org/jira/browse/JCR-2759
>             Project: Jackrabbit Content Repository
>          Issue Type: Improvement
>          Components: jackrabbit-core
>            Reporter: Marcel Reutegger
>            Priority: Minor
>         Attachments: JCR-2759.patch
> Executing a query with multiple OR expressions in a predicate leads to score values that
depend on the order of the operands.
> For example, the following query:
> //*[jcr:contains(@prop1, 'foo') or jcr:contains(@prop2, 'foo') or jcr:contains(@prop3,
'foo')] order by @jcr:score descending
> will return a slightly different result compared to:
> //*[jcr:contains(@prop3, 'foo') or jcr:contains(@prop1, 'foo') or jcr:contains(@prop2,
'foo')] order by @jcr:score descending
> Internally jackrabbit parses the predicate of the first query into a tree:
> orExpr(orExpr(contains(prop1, 'foo'), contains(prop2, 'foo')), contains(prop3, 'foo'))
> Lucene will calculate the score for the inner OR expression first and then for the outer,
which is not equivalent with a nested expression that has property names in a different sequence.
> The query should be translated internally into a single OR expression with three operands.
That way, the score value is always the same, irrespective of the order of the operands.

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message