[
https://issues.apache.org/jira/browse/SOLR-12139?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16421174#comment-16421174
]
David Smiley commented on SOLR-12139:
-------------------------------------
On the eve of committing, I'm very conflicted as I continue to mull over this.
Overloading "eq" here could introduce a subtle back-compat break with an
existing user if it doesn't detect the types correctly, and I suspect it's not
always resolvable. I was mulling over how to word that exactly in the
CHANGES.txt. And as I look at it in my IDE finally, the implementation here
becomes a bit odd in that it modifies SolrComparisonBoolFunction to in certain
cases completely ignore the {{Compare cmp}} field that is supposedly
fundamental to defining what an instance of this class is going to do, and
instead calls Object.equals.
To rectify the issues above, we could create a new subclass of
ComparisonBoolFunction explicitly for equality (thus avoiding the hack of
disregarding {{Compare cmp}}). And maybe instead of calling
Objects.equals(...,...) we check for Number subclasses? e.g.:
{code:java}
Object left, right;
if (left == null) return right == null;
if (right == null) return false;
if (left.class == right.class) return left.equals(right); // common case?
if (left instanceof Number && right instanceof Number) {
return ((Number)left).doubleValue() == ((Number)right).doubleValue();
}
return false; // or left.equals(right) despite that we know the classes are
different? Or throw exception.
{code}
The safest thing to do is add a new simple purpose-built ValueSource, perhaps
named "eq_str".... although admittedly it's yet another name when logically
"eq" ought to be appropriate enough.
[~mkhludnev] do you have any opinion?
> Support "eq" function for string fields
> ---------------------------------------
>
> Key: SOLR-12139
> URL: https://issues.apache.org/jira/browse/SOLR-12139
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: search
> Reporter: Andrey Kudryavtsev
> Priority: Minor
> Attachments: SOLR-12139.patch, SOLR-12139.patch, SOLR-12139.patch,
> SOLR-12139.patch
>
>
> I just discovered that {{eq}} user function will work for numeric fields only.
> For string types it results in {{java.lang.UnsupportedOperationException}}
> What do you think if we will extend it to support at least some of string
> types as well?
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
