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] [Resolved] (JCR-3603) Index aggreate with property include does not speed up order by
Date Thu, 30 May 2013 10:25:20 GMT

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

Marcel Reutegger resolved JCR-3603.

       Resolution: Fixed
    Fix Version/s: 2.7.1

SearchIndex now makes sure the normalized path is used.

Fixed in http://svn.apache.org/r1487803

Re-indexing the workspace is required to benefit again of the speed up for properties configured
with an include-property in the indexing configuration!
> Index aggreate with property include does not speed up order by
> ---------------------------------------------------------------
>                 Key: JCR-3603
>                 URL: https://issues.apache.org/jira/browse/JCR-3603
>             Project: Jackrabbit Content Repository
>          Issue Type: Bug
>          Components: jackrabbit-core
>    Affects Versions: 2.2, 2.3, 2.4, 2.6
>            Reporter: Marcel Reutegger
>             Fix For: 2.7.1
> JCR-800 introduced support for order by with a relative path in Jackrabbit 1.6. The feature
introduced two ways how sorting is implemented. One is based on reading the sort value from
the persistence manager and the second one uses internal lucene functionality to perform more
efficient sorting. The latter requires a customized indexing configuration with an aggregate
definition with a include-property for the property to order by. See also documentation on
the wiki: http://wiki.apache.org/jackrabbit/IndexingConfiguration
> Starting with Jackrabbit 2.2 the second sort mechanism is broken and the repository always
falls back to the first mechanism, which is considerably slower when the number of results
> The root cause is a subtle change of Path.computeRelativePath() in Jackrabbit 2.2. Previously
the implementation would return a *normalized* relative path. Starting with 2.2 the returned
path is not normalized and starts with a current node element.
> That is, previously (pseudo code):
> "/foo/bar".computeRelativePath("/foo") returned "bar"
> now:
> "/foo/bar".computeRelativePath("/foo") returns "./bar"
> The JavaDoc of the method does not say whether the returned path is normalized or not.
From this perspective the change in behavior is with the specified contract.

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

View raw message