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

Andrey Kudryavtsev commented on SOLR-12139:
-------------------------------------------

{quote}
 
 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...
 {quote}

+1

{quote}

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

{quote}

So it's a {{ValueSource}} which pretends to be numeric by nether extends 
{{LongDocValues}} / {{IntDocValues}} / {{DoubleDocValues}} / {{FloatDocValues}} 
nor implements {{objectVal(...)}} method. I personally feel like it would be 
better to fix such  {{ValueSources}} instead of making additional checks, but 
if a backward compatibility is a must have...having new equal function would 
work.


> 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
>            Assignee: David Smiley
>            Priority: Minor
>         Attachments: SOLR-12139.patch, 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

Reply via email to