[
https://issues.apache.org/jira/browse/JCR-3047?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13084246#comment-13084246
]
Alex Parvulescu commented on JCR-3047:
--------------------------------------
you are right!
so, here goes my quick fix: you remove getAffectedPropertyName, and use
operand.toString as a lucene field name.
In your example that would be: LENGTH(nt:base.p1)
By using this custom name, you then define a custom lucene index on this field,
where you can safely use evaluator.getValues(o1.getOperand(), node), which will
work.
This way we can get rid of that persky getAffectedPropertyName, and use a more
reliable source, the operand itself.
> 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
