[
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