[
https://issues.apache.org/jira/browse/SOLR-14800?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Smiley resolved SOLR-14800.
---------------------------------
Resolution: Won't Fix
After looking at this some more, I'm closing this as Won't-Fix. The FILTER
clause of a BooleanQuery scores as 0. So, I think FilterQuery should score
this way because I think its semantic meaning is as a filter (it's in its
name!) whereas DocSet.makeQuery (formerly getTopFilter) is generic. Leaving
that at 1.0 enables it to be boosted to 0 if desired but a user can't go the
other direction easily.
> Filter default score should be the provided boost, not zero
> -----------------------------------------------------------
>
> Key: SOLR-14800
> URL: https://issues.apache.org/jira/browse/SOLR-14800
> Project: Solr
> Issue Type: Sub-task
> Components: search
> Reporter: David Smiley
> Priority: Major
>
> I see some inconsistency in what some "constant scoring queries" return for a
> score. Lucene's ConstantScoreQuery yields 1 but it can be boosted (e.g.
> multiplied by whatever). SolrConstantScoreQuery (which wraps a Filter) does
> the same. Filter itself (which was modified to BE a Query years ago) yields
> 0 (not boostable), and so if it's used as a Query (vs only used as a supplier
> of DocIdSet), it's always 0. Nearly all ConstantScoreQuery usages use the
> provided boost (often indirectly via score() which is initialized to the
> boost), and do not hard-code 0. I think we should standardize on this
> approach.
> Note: ToParentBlockJoinQuery (and Child equivalent) use 0 (by code
> inspection) but this seems to be an anomaly.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
