[jira] [Resolved] (JCR-3603) Index aggreate with property include does not speed up order by

["Marcel Reutegger (JIRA)" <ji...@apache.org>]

     [ 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 increases.
> 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