Marcel Reutegger created JCR-3603:
-------------------------------------
Summary: 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.6, 2.4, 2.3, 2.2
Reporter: Marcel Reutegger
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
