lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Uwe Schindler (JIRA)" <j...@apache.org>
Subject [jira] Commented: (LUCENE-1518) Merge Query and Filter classes
Date Mon, 15 Jun 2009 14:08:07 GMT

    [ https://issues.apache.org/jira/browse/LUCENE-1518?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12719567#action_12719567
] 

Uwe Schindler commented on LUCENE-1518:
---------------------------------------

Push to 3.1! -- Uwe

> 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
>             Fix For: 2.9
>
>         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-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org


Mime
View raw message