[ 
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

Reply via email to