[ https://issues.apache.org/jira/browse/LUCENE-6328?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14351042#comment-14351042 ]
Paul Elschot commented on LUCENE-6328: -------------------------------------- OTOH Weight already has this: {code} public abstract Scorer scorer(LeafReaderContext context, Bits acceptDocs) throws IOException; {code} So the method that returns a (subclass of) DocIdSet gets a LeafReaderContext argument, which means that the Query-Segment split is already there. > Make Filter.clone and Filter.setBoost throw an UnsupportedOperationException > ---------------------------------------------------------------------------- > > Key: LUCENE-6328 > URL: https://issues.apache.org/jira/browse/LUCENE-6328 > Project: Lucene - Core > Issue Type: Bug > Reporter: Adrien Grand > Assignee: Adrien Grand > Priority: Minor > Fix For: Trunk, 5.1 > > Attachments: LUCENE-6328.patch > > > The rewrite process uses a combination of calls to clone() and > setBoost(boost) in order to rewrite queries. This is a bit weird for filters > given that they were not originally designed to care about scoring. > Using a filter directly as a query fails unit tests today since filters do > not pass the QueryUtils checks: it is expected that cloning and changing the > boost results in an instance which is unequal. However existing filters do > not take into account the getBoost() parameter inherited from Query so this > test fails. > I think it would be less error-prone to throw an > UnsupportedOperationException for clone() and setBoost() on filters and > disable the check in QueryUtils for filters. > In order to keep rewriting working, filters could rewrite to a CSQ around > themselves so that clone() and setBoost() would be called on the CSQ. -- This message was sent by Atlassian JIRA (v6.3.4#6332) --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org