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] Updated: (LUCENE-2838) ConstantScoreQuery should directly support wrapping Query and simply strip off scores
Date Tue, 28 Dec 2010 22:45:45 GMT

     [ https://issues.apache.org/jira/browse/LUCENE-2838?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Uwe Schindler updated LUCENE-2838:
----------------------------------

    Description: 
Especially in MultiTermQuery rewrite modes we often simply need to strip off scores from Queries
and make them constant score. Currently the code to do this looks quite ugly: new ConstantScoreQuery(new
QueryWrapperFilter(query))

As the name says, QueryWrapperFilter should make any other Query constant score, so why does
it not take a Query as ctor param? This question was aldso asked quite often by my customers
and is simply correct, if you think about it.

Looking closer into the code, it is clear that this would also speed up MTQs:
- One additional wrapping and method calls can be removed
- Maybe we can even deprecate QueryWrapperFilter in 3.1 now (it's now only used in tests and
the use-case for this class is not really available) and LUCENE-2831 does not need the stupid
hack to make Simon's assertions pass
- CSQ now supports out-of-order scoring and topLevel scoring, so a CSQ on top-level now directly
feeds the Collector. For that a small trick is used: The score(Collector) calls are directly
delegated and the scores are stripped by wrapping the setScorer() method in Collector

During that I found a visibility bug in Scorer: The method "boolean score(Collector collector,
int max, int firstDocID)" should be public not protected, as its not solely intended to be
overridden by subclasses and is called from other classes, too! This leads to no compiler
bugs as the other classes that calls it is mainly BooleanScorer(2) and thats in same package,
but visibility is wrong. I will open an issue for that and fix it at least in trunk where
we have no backwards-requirement.

  was:
Especially in MultiTermQuery rewrite modes we often simply need to strip off scores from Queries
and make them constant score. Currently the code to do this looks quite ugly: new ConstantScoreQuery(new
QueryWrapperFilter(query))

The name say, QueryWrapperFilter should make any other Query constant score, so why does it
not take a Query as ctor param. This question was aldso askedquite often by my customers and
is simply stupid.

Looking closer into the code, it is clear that this would also speed up MTQs:
- One additional wrapping and method calls can be removed
- Maybe we can even deprecate QueryWrapperFilter in 3.1 now (it's now only used in tests and
the use-case for this class is not really available) and LUCENE-2831 does not need the stupid
hack to make Simon's assertions pass
- CSQ now supports out-of-order scoring and topLevel scoring, so a CSQ on top-level now directly
feeds the Collector. For that a small trick is used: The score(Collector) calls are directly
delegated and the scores are stripped by wrapping the setScorer() method in Collector

During that I found a visibility bug in Scorer: The method "boolean score(Collector collector,
int max, int firstDocID)" should be public not protected, as its not solely intended to be
overridden by subclasses and is called from other classes, too! This leads to no compiler
bugs as the other classes that calls it is mainly BooleanScorer(2) and thats in same package,
but visibility is wrong. I will open an issue for that and fix it at least in trunk where
we have no backwards-requirement.


> ConstantScoreQuery should directly support wrapping Query and simply strip off scores
> -------------------------------------------------------------------------------------
>
>                 Key: LUCENE-2838
>                 URL: https://issues.apache.org/jira/browse/LUCENE-2838
>             Project: Lucene - Java
>          Issue Type: Improvement
>          Components: Search
>            Reporter: Uwe Schindler
>            Assignee: Uwe Schindler
>             Fix For: 3.1, 4.0
>
>         Attachments: LUCENE-2838.patch
>
>
> Especially in MultiTermQuery rewrite modes we often simply need to strip off scores from
Queries and make them constant score. Currently the code to do this looks quite ugly: new
ConstantScoreQuery(new QueryWrapperFilter(query))
> As the name says, QueryWrapperFilter should make any other Query constant score, so why
does it not take a Query as ctor param? This question was aldso asked quite often by my customers
and is simply correct, if you think about it.
> Looking closer into the code, it is clear that this would also speed up MTQs:
> - One additional wrapping and method calls can be removed
> - Maybe we can even deprecate QueryWrapperFilter in 3.1 now (it's now only used in tests
and the use-case for this class is not really available) and LUCENE-2831 does not need the
stupid hack to make Simon's assertions pass
> - CSQ now supports out-of-order scoring and topLevel scoring, so a CSQ on top-level now
directly feeds the Collector. For that a small trick is used: The score(Collector) calls are
directly delegated and the scores are stripped by wrapping the setScorer() method in Collector
> During that I found a visibility bug in Scorer: The method "boolean score(Collector collector,
int max, int firstDocID)" should be public not protected, as its not solely intended to be
overridden by subclasses and is called from other classes, too! This leads to no compiler
bugs as the other classes that calls it is mainly BooleanScorer(2) and thats in same package,
but visibility is wrong. I will open an issue for that and fix it at least in trunk where
we have no backwards-requirement.

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


Mime
View raw message