Mailing-List: contact java-dev-help@lucene.apache.org; run by ezmlm
Precedence: bulk
Reply-To: java-dev@lucene.apache.org
Message-ID: <1358551001.1234252619709.JavaMail.jira@brutus>
Date: Mon, 9 Feb 2009 23:56:59 -0800 (PST)
From: "Uwe Schindler (JIRA)" <jira@apache.org>
To: java-dev@lucene.apache.org
Subject: [jira] Issue Comment Edited: (LUCENE-1518) Merge Query and Filter
 classes
In-Reply-To: <799160766.1231789564104.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable


    [ https://issues.apache.org/jira/browse/LUCENE-1518?page=3Dcom.atlassia=
n.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=3D126=
72199#action_12672199 ]=20

thetaphi edited comment on LUCENE-1518 at 2/9/09 11:56 PM:
----------------------------------------------------------------

This patch does not want to completely merge queries and filters. It only g=
ives the possibility to use a Filter directly as a query. So ValueSourceQue=
ry will stay direct subclass of Query and not of Filter and can be used as =
scorer only. I think completely merging both is not a good idea.

But for easy usage, the idea of making filter automatically work as query (=
using a constant score algorithm) may be good. So queries (e.g. without mat=
ching, also conventional queries)  can stay alive, but filters can be used =
as query (and BooleanQuery could automatically have filters as clauses, and=
 is able to optimize and factor away scoring).

The user only has an easy understandable API and would not be affected with=
 thinking about "is it better to use a ConstantScoreQuery or should I just =
filter the results of the other boolean query clauses? What if I only have =
the filter, do I need a MatchAllDocsQuery and filter it, or better use Cons=
tantScore in this case?".

      was (Author: thetaphi):
    This patch does not want to completely merge queries and filters. It on=
ly gives the possibility to use a Filter directly as a query. So ValueSourc=
eQuery will stay direct subclass of Query and not of Filter and can be used=
 as scorer only. I think completely merging both is not a good idea.

But for easy usage, the idea of making filter automatically work as query (=
using a constant score algorithm) may be good. So queries (e.g. without mat=
ching, also conventional queries)  can stay alive, but filters can be used =
as query (and BooleanQuery could automatically have filters as clauses, and=
 is able to optimize and factor away scoring). The user only has a easy und=
erstandable API and would not be affected by thinking about ("is it better =
to use a ConstantScoreQuery or should I just filter the results other boole=
an query clauses?").
 =20
> 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, th=
at 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 ConstantScoreQ=
uery, deprecate ConstantScoreQuery. If somebody implements the Filter's get=
DocIdSet()/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 a=
lone a search query without any other constraint). For that, the abstract Q=
uery 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 f=
ilter (where the API wants a Filter), the getDocIdSet part could be directl=
y 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 Boole=
anQueries combining Filters and Queries the idea is, to optimize the Boolea=
nQuery 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 b=
urden 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 ev=
ery Filter is also a ConstantScoreQuery, the query can be executed and retu=
rns score 1.0 for all matching documents.
> - User runs Searcher.search() using a Query as the only parameter: No cha=
nge, all is the same as before
> - User runs Searcher.search() using a BooleanQuery as parameter: If the B=
ooleanQuery does not contain a Query that is subclass of Filter (the new Fi=
lter) everything as usual. If the BooleanQuery only contains exactly one Fi=
lter and nothing else the Filter is used as a constant score query. If Bool=
eanQuery 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 ca=
n just combine clauses together. The scorer/weight logic then identifies th=
e cases to use the filter or the query weight API. Just like the query opti=
mizer of a RDB.

--=20
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