[
https://issues.apache.org/jira/browse/JCR-3047?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jukka Zitting updated JCR-3047:
-------------------------------
Attachment: 0001-JCR-3047-OperandEvaluator-should-be-able-to-handle-N.patch
I'm not too much of a fan of duplicating so much of the code in
OperandEvaluator.
It would be nice if instead the Node to be used was simply wrapped into a
simple row instance with a default full text search score and then passed to
the existing code. The attached patch does this by moving the generic Row
implementations to -core to -jcr-commons and then using the SelectorRow class
in the OperandEvaluator to support also Nodes in addition to Rows.
PS. What's the use of the getAffectedPropertyName() method? Note that the
property under a given Operand also depends on the selector name, so just
getting the property name doesn't tell you much unless you already have more
context information for interpreting it (in which case you might already have
also the property name).
> 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
