Uploaded image for project: 'Jackrabbit Content Repository'
  1. Jackrabbit Content Repository
  2. JCR-3603

Index aggreate with property include does not speed up order by

    XMLWordPrintableJSON

Details

    • Bug
    • Status: Closed
    • Major
    • Resolution: Fixed
    • 2.2, 2.3, 2.4, 2.6
    • 2.6.5, 2.7.1, 2.4.6
    • jackrabbit-core
    • None

    Description

      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.

      Attachments

        Activity

          People

            Unassigned Unassigned
            mreutegg Marcel Reutegger
            Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved: