[
https://issues.apache.org/jira/browse/LUCENE-1771?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12742037#action_12742037
]
Mark Miller commented on LUCENE-1771:
-------------------------------------
I think the Changes entries could still use some polish.
Here are the originals:
3. LUCENE-1630: Deprecate Weight in favor of QueryWeight: added
matching methods to Searcher to take QueryWeight and deprecated
those taking Weight. If you have a Weight implementation, you can
turn it into a QueryWeight with QueryWeightWrapper (will be
removed in 3.0). All of the Weight-based methods were implemented
by calling the QueryWeight variants by wrapping the given Weight.
Going forward Searchable will be kept for convenience only and may
be changed between minor releases without any deprecation
process. It is not recommended to implement it, but rather extend
Searcher. (Shai Erera via Mike McCandless)
24. LUCENE-1630: Deprecate Weight in favor of QueryWeight, which adds
a scorer(IndexReader, boolean /* scoreDocsInOrder */, boolean /*
topScorer */) method instead of scorer(IndexReader) (now
deprecated). The new method is used by IndexSearcher to mate
between Collector and Scorer orderness of doc IDs. Some Scorers
(like BooleanScorer) are much more efficient if out-of-order
documents scoring is allowed by a Collector. Collector must now
implement acceptsDocsOutOfOrder. If you write a Collector which
does not care about doc ID orderness, it is recommended that you
return true. QueryWeight has the scoresDocsOutOfOrder method,
which by default returns false. If you create a QueryWeight which
will score documents out of order if that's requested, you should
override that method to return true. Also deprecated
BooleanQuery's setAllowDocsOutOfOrder and getAllowDocsOutOfOrder
as they are not needed anymore. BooleanQuery will now score docs
out of order when used with a Collector that can accept docs out
of order. (Shai Erera via Mike McCandless)
And I've changed to:
3. LUCENE-1630, LUCENE-1771: Weight, previously an interface, is now an
abstract
class. Some of the method signatures have changed, but it should be fairly
easy to see what adjustments must be made to existing code to sync up
with the new API. You can find more detail in the API Changes section.
Going forward Searchable will be kept for convenience only and may
be changed between minor releases without any deprecation
process. It is not recommended that you implement it, but rather extend
Searcher. (Shai Erera, Chris Hostetter, Mark Miller via Mike McCandless)
24. LUCENE-1630, LUCENE-1771: Weight is now an abstract class, andd adds
a scorer(IndexReader, boolean /* scoreDocsInOrder */, boolean /*
topScorer */) method instead of scorer(IndexReader). The new method
is used by IndexSearcher to mate Collector and Scorer orderness
of doc IDs. Some Scorers (like BooleanScorer) are much more efficient
if out-of-order documents scoring is allowed by a Collector. Collector
must now implement acceptsDocsOutOfOrder. If you write a Collector
which does not care about doc ID orderness, it is recommended that you
return true. Weight has a scoresDocsOutOfOrder method, which by default
returns false. If you create a Weight which will score documents out of
order if requested, you should override that method to return true.
BooleanQuery's setAllowDocsOutOfOrder and getAllowDocsOutOfOrder have
been deprecated as they are not needed anymore. BooleanQuery will now
score docs out of order when used with a Collector that can accept docs
out of order. Finally, Weight#explain now also takes a Searcher.
(Shai Erera, Chris Hostetter, Mark Miller via Mike McCandless)
So one thing I don't like is {quote} The new method is used by IndexSearcher to
mate Collector and Scorer orderness of doc IDs. {quote} I know what it means,
but its a bit vague and awkward. I'm not sure how to best rewrite it though.
Also, while the entry talks a lot about the orderedIds param, it doesn't really
mention the topScorer param. I'm still not 100% clear on it after looking at
the javadocs either (without looking at the code). I don't think top scorer can
be defined using primarily the term top scorer - it might as well be the omega
scorer unless you can point me to the Lucene dictionary where I can look it up:
{code}
* @param topScorer
* specifies whether the returned {...@link Scorer} will be used as a
* top scorer or as in iterator. I.e., if true,
* {...@link Scorer#score(Collector)} will be called; if false,
* {...@link Scorer#nextDoc()} and/or {...@link Scorer#advance(int)}
will
* be called.
{code}
So I still want to beef up these changes a bit, and I think the javadoc needs
to be a bit more clear - as we don't provide a convenience method that chooses
defaults for those params, it should be very easy to quickly figure out whats
best to pass. Right now, its just a little less than clear without some code
browsing.
> Using explain may double ram reqs for fieldcaches when using
> ValueSourceQuery/CustomScoreQuery or for ConstantScoreQuerys that use a
> caching Filter.
> ----------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: LUCENE-1771
> URL: https://issues.apache.org/jira/browse/LUCENE-1771
> Project: Lucene - Java
> Issue Type: Bug
> Components: Search
> Reporter: Mark Miller
> Assignee: Mark Miller
> Fix For: 2.9
>
> Attachments: LUCENE-1771.bc-tests.patch, LUCENE-1771.patch,
> LUCENE-1771.patch, LUCENE-1771.patch, LUCENE-1771.patch, LUCENE-1771.patch,
> LUCENE-1771.patch, LUCENE-1771.patch, LUCENE-1771.patch, LUCENE-1771.patch
>
>
--
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: [email protected]
For additional commands, e-mail: [email protected]
