You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by "David Smiley (JIRA)" <ji...@apache.org> on 2018/05/09 21:09:00 UTC

[jira] [Commented] (SOLR-12336) Remove or refactor Filter

    [ https://issues.apache.org/jira/browse/SOLR-12336?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16469502#comment-16469502 ] 

David Smiley commented on SOLR-12336:
-------------------------------------

Some possible sub-tasks:
* Remove SolrConstantScoreQuery.  It's a constant scoring Query that wraps around a Filter.  A sad irony is that Filter *is* a Query, and is constant scoring.  It seems to exist to support a quirky special-case "SolrFilter" (dubious name). It also implements ExtendedQuery but we have others like WrappedQuery for that.  (ExtendedQueryWrapper would have been a better name) 
* Remove SolrFilter.  It's an abstract subclass of Filter that ensures createWeight is called.  The only subclass is ValueSourceRangeFilter.  It seems VSRF could extend Filter directly and intercept createWeight to do this?  TestFunctionQuery has applicable tests.

Then figure out what we do with Filter.  Perhaps it ought not to extend Query as it's a bit confusing.

> Remove or refactor Filter
> -------------------------
>
>                 Key: SOLR-12336
>                 URL: https://issues.apache.org/jira/browse/SOLR-12336
>             Project: Solr
>          Issue Type: Improvement
>      Security Level: Public(Default Security Level. Issues are Public) 
>          Components: search
>            Reporter: David Smiley
>            Priority: Major
>
> 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
(v7.6.3#76005)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org