[
https://issues.apache.org/jira/browse/SOLR-12139?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16422685#comment-16422685
]
David Smiley commented on SOLR-12139:
-------------------------------------
bq. 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.
That's not what I'm saying; I'm not implying any ValueSource/FunctionValues
impls are broken. I'm suggesting someone right now has a something like this:
eq(5,def(fieldA,5)) wherein fieldA is a "double" field. eq() will check the
left and find a numeric that is either int/long. Then it will evaluate the
right side and not know what it is so it uses the object comparison. Lets say
that a document has 5.0 in this field on a particular document.
Integer.equals(Double ...) will fail even though 5.0 == 5. I believe that
works today but not with this patch. We should have a test for this here.
BTW for efficiency we may want to say that if *either* left or right is a known
numeric FunctionValues type then do double comparison (instead of insisting on
both). It doesn't make sense to compare a numeric field with something
non-numeric any way. The change I suggest with this statement is a simple
switch of "&&" to "||" in createComparator.
> 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
