[
https://issues.apache.org/jira/browse/SOLR-7513?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14593611#comment-14593611
]
Joel Bernstein edited comment on SOLR-7513 at 6/19/15 4:40 PM:
---------------------------------------------------------------
First impression is that it all looks good. I like the StreamComparator
introduced in SOLR-7528 and the Equalitors are a nice design. I'll review the
changes and run all the tests.
was (Author: joel.bernstein):
First impression that it all looks good. I like the StreamComparator introduced
in SOLR-7528 and Equalitors are a nice design. I'll review the changes some and
run all the tests.
> 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
>
>
> 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]
