jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Marcel Reutegger (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (JCR-3603) Index aggreate with property include does not speed up order by
Date Thu, 28 Nov 2013 14:26:35 GMT

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

View raw message