[ 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.4.6 Merged into 2.4 branch in http://svn.apache.org/r1546371 > 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.4.6, 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)