[
https://issues.apache.org/jira/browse/LUCENE-2838?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Uwe Schindler updated LUCENE-2838:
----------------------------------
Attachment: LUCENE-2838.patch
Cleaned up patch:
- removed a useless testcase, no longer needed
- added test for CSQ, that checks equals and hashCode
- code cleanup
- javadocs
I will commit this if nobody objects to 3.x and trunk. About deprecating QWF we
should discuss in separate issues, maybe we can merge Filter and Query before
4.0!
> 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, 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 (LUCENE-2839): 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-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
