[dna-issues] [JBoss JIRA] Commented: (DNA-613) XPath order-by clause is not working

[ https://jira.jboss.org/jira/browse/DNA-613?page=com.atlassian.jira.plugin... ] Randall Hauch commented on DNA-613: ----------------------------------- One problem was when there was an ORDER BY SCORE(selectorName) when the selector was a view that joined multiple tables. In this case, the score function would need to be resolved against the scores from multiple source tables. The existing FullTextSearchScore subclass of DynamicOperand required a single selector name, so it was not possible to represent a single DynamicOperand that represented the score from multiple tables. One option considered was the creation of a FullTextSearchCompositeScore that would accept multiple selector names. Unfortunately, DynamicOperand makes the assumption that it only applies to a single selector, and thus has a 'getSelectorName()' method. This could be changed to no longer make this assumption (as well as adjust all places that use this method), but the composite score DynamicOperand seems to be a bit of a hack. Instead, I decided that it was better to support a DynamicOperand that represented an arithmetic operation between two other DynamicOperands, and thus there is a new ArithmeticOperand class that contains a left DynamicOperand, an arithmetic operator, and a right DynamicOperand. And of course, ArithmeticOperands can be nested inside each other to create relatively complex operations. Because an ArithmeticOperand applies to two DynamicOperands, those DynamicOperands might apply to different selectors. Thus, this approach also required changing DynamicOperand.getSelectorName():SelectorName to getSelectorNames():Set<SelectorName>. Also, it was critical for this set to maintain the order of insertion of the set, so a LinkedHashSet was used. This addition required changes to the SQL parser, the planner, and the optimizer (along with the corresponding tests). The change to multiple selector names for DynamicOperand also required changes to all other DynamicOperand subclasses, and the code that used these methods. Another change was made to the PlanHints so that a string representation of the query plan could be requested and placed in the results. In the JCR layer, this was leveraged by always requesting the plan and then making the string representation of the plan publicly available on the JcrQueryResult class. Finally, there were changes made to the way the XPath-to-SQL translator works (along with the test cases). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira