[ 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

[ https://jira.jboss.org/jira/browse/DNA-613?page=com.atlassian.jira.plugin... ] Randall Hauch commented on DNA-613: ----------------------------------- Found several minor issues that all conspired to make this functionality not work. 1) The XPathToQueryTranslator was incorrectly translating queries that used wildcards in the path. 2) Queries that used aliases in columns, criteria, or order-by clauses were not always being resolved correctly, resulting in the inability to locate the correct column (when constraints or order-by clauses had to be evaluated after the fact. 3) The optimizer was not always pushing SELECT nodes (e.g., criteria) down below ACCESS nodes. The rule to do this was not included by default and was instead added to the rule stack only when criteria were encountered. This was changed to simply always add the rule to the stack. 4) Columns used in constraints or order-by clauses were not always being included in the PROJECT columns. Thus it was possible that the evaluation of the criteria or order-by required data that was not in the tuples, causing an error. Note that these PROJECT columns dictate which values are included in the tuples during processing, and all of these are not necessarily included in the result columns. 5) The LuceneSearchEngine was incorrectly mapping paths into criteria values that could be applied to Lucene. If the user specified a criteria such as PATH(table) LIKE '/Cars/Hybrid/%' the "/Cars/Hybrid/%" value was used directly as the LIKE expression. But paths are stored in the indexes so that the SNS index is always included, and thus the LIKE expressions never evaluated to return any documents. Since the SNS index in the path might include the wildcard characters (e.g., '[%]' or '[_]'), we couldn't use the standard PathFactory to convert the LIKE expression value into a Path. The solution was to just use String manipulation to insert a '[1]' at the end of each segment that didn't already include a SNS index. 6) Lucene 'read past EOF' errors; see DNA-630. -- 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

[ https://jira.jboss.org/jira/browse/DNA-613?page=com.atlassian.jira.plugin... ] Randall Hauch resolved DNA-613. ------------------------------- Resolution: Done -- 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