You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@lucene.apache.org by "David Smiley (Jira)" <ji...@apache.org> on 2020/05/17 15:59:00 UTC
[jira] [Commented] (SOLR-12336) Remove Filter from Solr
[ https://issues.apache.org/jira/browse/SOLR-12336?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17109539#comment-17109539 ]
David Smiley commented on SOLR-12336:
-------------------------------------
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. ToParentBlockJoinQuery (and Child equivalent) and _maybe_ all other constant scoring Queries in Lucene's join module use 0 as well. My intuition, however, is that the vast majority of Lucene's "constant scoring queries" use 1, so maybe the join module is an exception? Ideally a thorough investigation on this would occur but I'm not sure I have time for that.
I raise this issue here because refactorings to not use Filter (like SOLR-14494 CC [~mkhl]) might want to consider this matter. My preference is simply to use 1 everywhere (I'll raise this on the dev list) but perhaps any 8x backports need to emulate the former behavior, perhaps via BoostQuery with 0 wrapper. I suspect this matter is very much an edge case because most people are using such queries as a filter instead of incorporating with a scoring query.
> Remove Filter from Solr
> -----------------------
>
> Key: SOLR-12336
> URL: https://issues.apache.org/jira/browse/SOLR-12336
> Project: Solr
> Issue Type: Improvement
> Components: search
> Reporter: David Smiley
> Assignee: David Smiley
> Priority: Major
> Fix For: master (9.0)
>
>
> Over a series of Lucene releases, the old Filter was made to extend Query (LUCENE-1518) and then was removed from Lucene (moved to Solr in LUCENE-6583); BooleanClause.Occur.FILTER (LUCENE-6227) with some other API enhancements including TwoPhaseIterator replaced the need for the old Filter. Filter is now a Solr thing, and there are various related classes like QueryWrapperFilter and SolrConstantScoreQuery that depend on it. We should remove some of this technical-debt / bit-rot, making refactorings as needed to retain functionality. Leaving things as-is is needless complexity and can impede performance when there is needless wrapping/layers.
> CC @yonik
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@lucene.apache.org
For additional commands, e-mail: issues-help@lucene.apache.org