[
https://issues.apache.org/jira/browse/SOLR-14800?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17492926#comment-17492926
]
Chris M. Hostetter commented on SOLR-14800:
-------------------------------------------
[~dsmiley] i'm a little late to the party, but your conclusion matches my
initial impression in reading your question: I would expect that Query
classes/objects that can only be used for filtering should conceptually produce
scores of '0' so that if they are embedded as a nested clause in a larger
query -- they should affect the final "match" status of each document, but not
the final "score" (and IIRC lucene Similarity no longer has things like coord
or queryNorm so matching a 0-score clause shouldn't "bring down" the score of a
document)
If "filter" clauses had a score of "1" that could potentially "increase" the
score of a document if the other clauses all had scores in the range {{0..1}}
> 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: [email protected]
For additional commands, e-mail: [email protected]
