[
https://issues.apache.org/jira/browse/JCR-800?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12673871#action_12673871
]
Marcel Reutegger commented on JCR-800:
--------------------------------------
> Question about the RelPathScoreDocComparator.sortValue(ScoreDoc i) : Will for
> every comparison the property value be refetched
> through the ISM?
That's correct.
> If so, temporal storing the result of sortValue might be necessary because
> this easily blows up cpu if it is not cached temporarily.
when you say temporarily, do you mean while a single result is sorted, or for a
longer period. The problem with caching here is, when the cache needs to be
invalidated. e.g. a node might get moved that is part of a relative path to a
sort property.
> Perhaps it might be easier to constrain sorting on child axis only for
> childnodes that are indexed through aggregates.
This will not work, because aggregates only consist of content that are
fulltext indexed on the node scope. But my idea is, to extend the indexing
configuration with entries for properties with a relative path. Those
properties are then to the node where they are referenced from. Similarly to
how aggregates work.
> Child Axis support in order by clause
> -------------------------------------
>
> Key: JCR-800
> URL: https://issues.apache.org/jira/browse/JCR-800
> Project: Jackrabbit Content Repository
> Issue Type: Improvement
> Components: jackrabbit-core, jackrabbit-spi-commons, xpath
> Reporter: Savvas Triantafyllou
> Fix For: 1.6.0
>
> Attachments: JCR-800-core.patch, JCR-800-spi-commons.patch
>
>
> Hi,
> since child axis is supported in XPath predicates, it would be nice to
> support it in order by clause as well
> Queries of type
> //element(*, type) [ foo/@bar ] order by foo/@bar asc
> can become very useful
> BR,
> Savvas
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
