lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mark Miller (JIRA)" <j...@apache.org>
Subject [jira] Commented: (LUCENE-1771) Using explain may double ram reqs for fieldcaches when using ValueSourceQuery/CustomScoreQuery or for ConstantScoreQuerys that use a caching Filter.
Date Tue, 11 Aug 2009 20:08:14 GMT

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


Mime
View raw message