[
https://issues.apache.org/jira/browse/SOLR-9279?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15368659#comment-15368659
]
Hoss Man commented on SOLR-9279:
--------------------------------
I didn't look at the pull request in depth, but in general i applaud the idea
and the general approach from skimming the issue description and
CompareNumericFunction.java
3 things that did jump out at me when skimming the patch as a whole:
* i see edits to ValueSourceParser.java but no edits to QueryEqualityTest.java
... that gives me 99% confidence that this patch breaks QueryEqualityTest
* I see tests of using these new functions when wrapped in {{if(...)}} but no
(obvious to me) tests of these new functions being used directly for their
return value -- ex: {{fl=id,gte(price,0)}} -- and demonstrating what the
expected result should be
** in this example, i would expect the result type to be a Boolean (ie: {{<bool
name="gte(price,0)">true</bool>}}
** Since i don't see {{FunctionValues.objectVal}} overridden anywhere in the
patch, i'm assuming this doesn't work as I expect
* I don't see {{FunctionValues.exists}} overridden anywhere in this patch,
which IIRC means these functions are always going to "exists=true", which does
not seem like a good hardcoded behavior for a ValueSource thta wraps other
ValueSources.
** some thought/javadocs should be given to how exactly these functions should
behave if/when one or more of the ValueSources they wrap do not exist for a
given document -- and some tests demonstrating the expected behavior in these
situations seem crucial.
** see LUCENE-5961, and the core premise expressed in the first comment on that
issue, which seems just as relevant to me for this issue.
** I would suggest implementing {{exists}} using
{{MultiFunction.allExists(...)}}, that way callers can decide for themselves
how it should behave, by wrapping the inner ValueSources in DefFunction, and/or
by wrapping their CompareNumericFunction in a DefFunction as they see fit.
> Add greater than, less than, etc in Solr function queries
> ---------------------------------------------------------
>
> Key: SOLR-9279
> URL: https://issues.apache.org/jira/browse/SOLR-9279
> Project: Solr
> Issue Type: New Feature
> Security Level: Public(Default Security Level. Issues are Public)
> Components: search
> Reporter: Doug Turnbull
> Fix For: master (7.0)
>
>
> If you use the "if" function query, you'll often expect to be able to use
> greater than/less than functions. For example, you might want to boost books
> written in the past 7 years. Unfortunately, there's no "greater than"
> function query that will return non-zero when the lhs > rhs. Instead to get
> this, you need to create really awkward function queries like I do here
> (http://opensourceconnections.com/blog/2014/11/26/stepwise-date-boosting-in-solr/):
> if(min(0,sub(ms(mydatefield),sub(ms(NOW),315569259747))),0.8,1)
> The pull request attached to this Jira adds the following function queries
> (https://github.com/apache/lucene-solr/pull/49)
> -gt(lhs, rhs) (returns 1 if lhs > rhs, 0 otherwise)
> -lt(lhs, rhs) (returns 1 if lhs < rhs, 0 otherwise)
> -gte
> -lte
> -eq
> So instead of
> if(min(0,sub(ms(mydatefield),sub(ms(NOW),315569259747))),0.8,1)
> one could now write
> if(lt(ms(mydatefield),315569259747,0.8,1)
> (if mydatefield < 315569259747 then 0.8 else 1)
> A bit more readable and less puzzling
--
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
