[ https://issues.apache.org/jira/browse/SOLR-9279?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15364281#comment-15364281 ]
ASF GitHub Bot commented on SOLR-9279: -------------------------------------- Github user softwaredoug commented on a diff in the pull request: https://github.com/apache/lucene-solr/pull/49#discussion_r69726431 --- Diff: lucene/queries/src/java/org/apache/lucene/queries/function/valuesource/CompareNumericFunction.java --- @@ -0,0 +1,131 @@ +package org.apache.lucene.queries.function.valuesource; + +/* + * Licensed to the Apache Software Foundation (ASF) under one or more + * contributor license agreements. See the NOTICE file distributed with + * this work for additional information regarding copyright ownership. + * The ASF licenses this file to You under the Apache License, Version 2.0 + * (the "License"); you may not use this file except in compliance with + * the License. You may obtain a copy of the License at + * + * http://www.apache.org/licenses/LICENSE-2.0 + * + * Unless required by applicable law or agreed to in writing, software + * distributed under the License is distributed on an "AS IS" BASIS, + * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. + * See the License for the specific language governing permissions and + * limitations under the License. + */ + +import java.io.IOException; +import java.util.Map; + +import org.apache.lucene.index.LeafReaderContext; +import org.apache.lucene.queries.function.ValueSource; +import org.apache.lucene.queries.function.FunctionValues; +import org.apache.lucene.search.IndexSearcher; + + +/** + * Base class for comparison operators used within if statements + * To Solr's if function query a 0 is considered "false", all other values are "true" + */ +public abstract class CompareNumericFunction extends ValueSource { + + public final ValueSource lhs; + public final ValueSource rhs; + + public CompareNumericFunction(ValueSource lhs, ValueSource rhs) { + this.lhs = lhs; + this.rhs = rhs; + } + + // Perform the comparison, returning true or false + public abstract boolean compareNumeric(double lhs, double rhs); --- End diff -- I think I like this idea in general, it would get rid of a lot of cruft. I can pass a lot in as constructor args instead of creating lots of noisy classes. I'm not sure I want to use LongBinaryPredicate (do you mean [LongPredicate](https://docs.oracle.com/javase/8/docs/api/java/util/function/LongPredicate.html)?. Taking a glance it seems like the value in using it would be in the support for and/or/not operators in a Java-consistent way. It would be nice, though a bit out of scope for this PR, to extend this idea to the other boolean operations so that valuesource's were compatible with this API. Let me push up a change that makes more anonymous instances and let me know what you think (I'll model in on how and, or, xor, etc are done) > 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