[ https://issues.apache.org/jira/browse/SOLR-7377?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14528339#comment-14528339 ]
Dennis Gove commented on SOLR-7377: ----------------------------------- I believe I've found a bug in FieldComparator. I don't have time to create a new patch right now, but the bug is not checking for null on the field before calling compare. Fixed version is below {code:java} private void assignComparator(){ if(ComparatorOrder.DESCENDING == order){ // What black magic is this type intersection?? // Because this class is serializable we need to make sure the lambda is also serializable. // This can be done by providing this type intersection on the definition of the lambda. // Why not do it in the lambda interface? Functional Interfaces don't allow extends clauses comparator = (ComparatorLambda & Serializable)(leftTuple, rightTuple) -> { Comparable leftComp = (Comparable)leftTuple.get(leftField); Comparable rightComp = (Comparable)rightTuple.get(rightField); if(null == leftComp){ return -1; } if(null == rightComp){ return 1; } return rightComp.compareTo(leftComp); }; } else{ // See above for black magic reasoning. comparator = (ComparatorLambda & Serializable)(leftTuple, rightTuple) -> { Comparable leftComp = (Comparable)leftTuple.get(leftField); Comparable rightComp = (Comparable)rightTuple.get(rightField); if(null == leftComp){ return -1; } if(null == rightComp){ return 1; } return leftComp.compareTo(rightComp); }; } } {code} > SOLR Streaming Expressions > -------------------------- > > Key: SOLR-7377 > URL: https://issues.apache.org/jira/browse/SOLR-7377 > Project: Solr > Issue Type: Improvement > Components: clients - java > Reporter: Dennis Gove > Priority: Minor > Fix For: Trunk > > Attachments: SOLR-7377.patch, SOLR-7377.patch, SOLR-7377.patch, > SOLR-7377.patch, SOLR-7377.patch, SOLR-7377.patch, SOLR-7377.patch, > SOLR-7377.patch > > > It would be beneficial to add an expression-based interface to Streaming API > described in SOLR-7082. Right now that API requires streaming requests to > come in from clients as serialized bytecode of the streaming classes. The > suggestion here is to support string expressions which describe the streaming > operations the client wishes to perform. > {code:java} > search(collection1, q=*:*, fl="id,fieldA,fieldB", sort="fieldA asc") > {code} > With this syntax in mind, one can now express arbitrarily complex stream > queries with a single string. > {code:java} > // merge two distinct searches together on common fields > merge( > search(collection1, q="id:(0 3 4)", fl="id,a_s,a_i,a_f", sort="a_f asc, a_s > asc"), > search(collection2, q="id:(1 2)", fl="id,a_s,a_i,a_f", sort="a_f asc, a_s > asc"), > on="a_f asc, a_s asc") > // find top 20 unique records of a search > top( > n=20, > unique( > search(collection1, q=*:*, fl="id,a_s,a_i,a_f", sort="a_f desc"), > over="a_f desc"), > sort="a_f desc") > {code} > The syntax would support > 1. Configurable expression names (eg. via solrconfig.xml one can map "unique" > to a class implementing a Unique stream class) This allows users to build > their own streams and use as they wish. > 2. Named parameters (of both simple and expression types) > 3. Unnamed, type-matched parameters (to support requiring N streams as > arguments to another stream) > 4. Positional parameters > The main goal here is to make streaming as accessible as possible and define > a syntax for running complex queries across large distributed systems. -- This message was sent by Atlassian JIRA (v6.3.4#6332) --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org