[
https://issues.apache.org/jira/browse/JCR-3603?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marcel Reutegger updated JCR-3603:
----------------------------------
Fix Version/s: 2.6.5
Merged into 2.6 branch in http://svn.apache.org/r1546362
> 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.6.5, 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 was sent by Atlassian JIRA
(v6.1#6144)
