[
https://issues.apache.org/jira/browse/JCR-3047?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13084221#comment-13084221
]
Alex Parvulescu commented on JCR-3047:
--------------------------------------
Yes I agree :)
To map Orderings to properties, you can use getAffectedPropertyName, otherwise
there is no way of knowing from a list of Orderings which goes where.
So you can go from (o1, o2) to a map p1 -> o1, p2 -> o2
After having this info, you can create a custom sort field in lucene (one for
p1 and another one for p2) that can apply via OperandEvaluator all the above
mentioned functions, like v1 = evaluator.getValues(o1.getOperand(), node), then
sort on v1, and so on
But this sorting related talk should happen on the other issue, 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
