Constant Scoring Queries; inconsistent approaches

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Constant Scoring Queries; inconsistent approaches

David Smiley
I see some inconsistency in what some "constant scoring queries" return for a score.  Ultimately, I'm arguing here for consistency in 9.0, and perhaps a bit of documentation clarity on such Queries.  It's an edge-case because typical constant scoring queries are used with org.apache.lucene.search.BooleanClause.Occur#FILTER or similar where it simply doesn't matter.  But nonetheless it's possible to combine it with other queries in a BooleanQuery and the choice has an impact.

Lucene's ConstantScoreQuery yields 1 but it can be boosted (e.g. multiplied by whatever).  Many other constant scoring queries in Lucene do likewise by using ConstantScoreWeight and propagating the "boost" parameter.  Picking one query at random doing this is DocValuesFieldExistsQuery.

However, I found some that choose 0 which isn't boostablle (because zero times anything is zero). ToParentBlockJoinQuery (and Child equivalent) use 0.  Solr's Filter.java (formerly in Lucene), which I'm slowly removing, chooses 0 as well.

Shall we standardize on a score of 1 for Lucene/Solr 9.0?  Or 0?  Or do some queries break with the norm for a good reason?

~ David Smiley
Apache Lucene/Solr Search Developer
Reply | Threaded
Open this post in threaded view
|

Re: Constant Scoring Queries; inconsistent approaches

Mikhail Khludnev-2
Hello, David. 
Having 1 as a score is a good idea. 

On Sun, May 17, 2020 at 7:25 PM David Smiley <[hidden email]> wrote:
I see some inconsistency in what some "constant scoring queries" return for a score.  Ultimately, I'm arguing here for consistency in 9.0, and perhaps a bit of documentation clarity on such Queries.  It's an edge-case because typical constant scoring queries are used with org.apache.lucene.search.BooleanClause.Occur#FILTER or similar where it simply doesn't matter.  But nonetheless it's possible to combine it with other queries in a BooleanQuery and the choice has an impact.

Lucene's ConstantScoreQuery yields 1 but it can be boosted (e.g. multiplied by whatever).  Many other constant scoring queries in Lucene do likewise by using ConstantScoreWeight and propagating the "boost" parameter.  Picking one query at random doing this is DocValuesFieldExistsQuery.

However, I found some that choose 0 which isn't boostablle (because zero times anything is zero). ToParentBlockJoinQuery (and Child equivalent) use 0.  Solr's Filter.java (formerly in Lucene), which I'm slowly removing, chooses 0 as well.

Shall we standardize on a score of 1 for Lucene/Solr 9.0?  Or 0?  Or do some queries break with the norm for a good reason?

~ David Smiley
Apache Lucene/Solr Search Developer


--
Sincerely yours
Mikhail Khludnev