[
https://issues.apache.org/jira/browse/JCR-3047?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13084236#comment-13084236
]
Jukka Zitting commented on JCR-3047:
------------------------------------
The mapping you suggest doesn't work. Consider "ORDER BY LENGTH(p1), p1" which
is supposed to order results first by the length and then by the contents of a
property. That's probably not a very likely scenario, but ideally the
implementation should be able to handle also cases like that.
More generally, you'll lose any performance benefits as soon as the custom
Lucene sort field tries to access the full node instance. More about this in
JCR-2959.
> OperandEvaluator should be able to handle Nodes as well, not just Rows
> ----------------------------------------------------------------------
>
> Key: JCR-3047
> URL: https://issues.apache.org/jira/browse/JCR-3047
> Project: Jackrabbit Content Repository
> Issue Type: Improvement
> Components: jackrabbit-jcr-commons
> Reporter: Alex Parvulescu
> Assignee: Alex Parvulescu
> Priority: Trivial
> Fix For: 2.3.0
>
> Attachments:
> 0001-JCR-3047-OperandEvaluator-should-be-able-to-handle-N.patch
>
>
> OperandEvaluator is used to evaluate Operands values against given Rows, and
> in an effort to improve the sorting part of SQL2 (JCR-2959), I need it to
> handle plain Nodes as well.
> This is a small change, as the OperandEvaluator already extracts the Node
> info from the Row, so there is no obvious reason no to expose the Node
> operations directly.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
