[ 
https://issues.apache.org/jira/browse/SOLR-7513?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14593739#comment-14593739
 ] 

Joel Bernstein commented on SOLR-7513:
--------------------------------------

This patch looks good to me and we have some pretty good tests behind it. the 
Streaming API tests, the Streaming Expressions tests and the Parallel SQL tests 
all exercise this code base. I plan to commit this to trunk shortly.

> Add Equalitors to Streaming Expressions
> ---------------------------------------
>
>                 Key: SOLR-7513
>                 URL: https://issues.apache.org/jira/browse/SOLR-7513
>             Project: Solr
>          Issue Type: Improvement
>          Components: clients - java
>    Affects Versions: Trunk
>            Reporter: Dennis Gove
>            Assignee: Joel Bernstein
>            Priority: Minor
>             Fix For: 5.3
>
>         Attachments: SOLR-7513.patch, SOLR-7513.patch, SOLR-7513.patch, 
> SOLR-7513.patch
>
>
> Right now all streams use the Comparator<Tuple> interface to compare tuples. 
> The Comparator interface will tell you if tupleA is before, after, or equal 
> to tupleB. This is great for most streams as they use this logic when 
> combining multiple streams together. However, some streams only care about 
> the equality of two tuples and the less/greater than logic is unnecessary.
> This depends on SOLR-7377.
> This patch is to introduce a new interface into streaming expressions called 
> Equalitor<Tuple> which will return if two tuples are equal. The benefit here 
> is that the expressions for streams using Equalitor instead of Comparator can 
> omit the ordering part.
> {code}
> unique(somestream, over="fieldA asc, fieldB desc")
> {code}
> can become
> {code}
> unique(somestream, over="fieldA,fieldB")
> {code}
> The added benefit is that this will set us up with simplier expressions for 
> joins (hash, merge, inner, outer, etc...) as those only care about equality.
> By adding this as an interface we make no assumptions about what it means to 
> be equal, just that some implementation needs to exist adhering to the 
> Equalitor<Tuple> interface which will determine if two tuples are logically 
> equal. 
> We do define at least one concrete class which checks for equality but that 
> does not preclude others from adding additional concrete classes with their 
> own logic in place.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to