[ https://issues.apache.org/jira/browse/LUCENE-1518?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12663133#action_12663133 ]
Jason Rutherglen commented on LUCENE-1518: ------------------------------------------ Hopefully this will allow caching of individual term queries even if they are a part of a boolean query? > Merge Query and Filter classes > ------------------------------ > > Key: LUCENE-1518 > URL: https://issues.apache.org/jira/browse/LUCENE-1518 > Project: Lucene - Java > Issue Type: Improvement > Components: Search > Affects Versions: 2.4 > Reporter: Uwe Schindler > Attachments: LUCENE-1518.patch > > > This issue presents a patch, that merges Queries and Filters in a way, that > the new Filter class extends Query. This would make it possible, to use every > filter as a query. > The new abstract filter class would contain all methods of > ConstantScoreQuery, deprecate ConstantScoreQuery. If somebody implements the > Filter's getDocIdSet()/bits() methods he has nothing more to do, he could > just use the filter as a normal query. > I do not want to completely convert Filters to ConstantScoreQueries. The idea > is to combine Queries and Filters in such a way, that every Filter can > automatically be used at all places where a Query can be used (e.g. also > alone a search query without any other constraint). For that, the abstract > Query methods must be implemented and return a "default" weight for Filters > which is the current ConstantScore Logic. If the filter is used as a real > filter (where the API wants a Filter), the getDocIdSet part could be directly > used, the weight is useless (as it is currently, too). The constant score > default implementation is only used when the Filter is used as a Query (e.g. > as direct parameter to Searcher.search()). For the special case of > BooleanQueries combining Filters and Queries the idea is, to optimize the > BooleanQuery logic in such a way, that it detects if a BooleanClause is a > Filter (using instanceof) and then directly uses the Filter API and not take > the burden of the ConstantScoreQuery (see LUCENE-1345). > Here some ideas how to implement Searcher.search() with Query and Filter: > - User runs Searcher.search() using a Filter as the only parameter. As every > Filter is also a ConstantScoreQuery, the query can be executed and returns > score 1.0 for all matching documents. > - User runs Searcher.search() using a Query as the only parameter: No change, > all is the same as before > - User runs Searcher.search() using a BooleanQuery as parameter: If the > BooleanQuery does not contain a Query that is subclass of Filter (the new > Filter) everything as usual. If the BooleanQuery only contains exactly one > Filter and nothing else the Filter is used as a constant score query. If > BooleanQuery contains clauses with Queries and Filters the new algorithm > could be used: The queries are executed and the results filtered with the > filters. > For the user this has the main advantage: That he can construct his query > using a simplified API without thinking about Filters oder Queries, you can > just combine clauses together. The scorer/weight logic then identifies the > cases to use the filter or the query weight API. Just like the query > optimizer of a RDB. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. --------------------------------------------------------------------- To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org For additional commands, e-mail: java-dev-h...@lucene.apache.org