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

Dennis Gove commented on SOLR-7513:
-----------------------------------

I appreciate the help with this, Joel. Thanks!

> 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: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Reply via email to