lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alan Woodward (JIRA)" <>
Subject [jira] [Commented] (LUCENE-7736) Expose some IndexReader stats via DoubleValuesSources
Date Thu, 19 Oct 2017 08:25:00 GMT


Alan Woodward commented on LUCENE-7736:

bq. two instances that have been built on a different reader will be considered equals

This is true, but there aren't really any circumstances under which it would happen.  Comparison
for equality is done when building queries or sorts, and these are indexreader independent.
 It's only after a rewrite that the values would actually be different, and the only callers
of rewrite are internal lucene classes.  It would be nice to enforce this somehow by making
rewrite() protected, but unfortunately I think it's called from different packages/modules
so this won't work.

bq. Should we use == rather than equals

Will do.

bq. Did you remove the if (boost == 1f) return expl; from FunctionScoreQuery on purpose?

Yes; just returning the straight DVS explanation breaks things when the overall query matches,
but the value source has no value - we end up returning Explanation.noMatch() from a document
that matches, but has a zero score.

re TermFreqDoubleValuesSource that's a nice idea, I'll add a DoubleValues.EMPTY instance and
use that.

bq. rewriting only once is enough

Yes!  Perhaps I should add some javadoc making that explicit.  I really dislike the 'rewrite
until things stay the same' API on Query...

> Expose some IndexReader stats via DoubleValuesSources
> -----------------------------------------------------
>                 Key: LUCENE-7736
>                 URL:
>             Project: Lucene - Core
>          Issue Type: New Feature
>            Reporter: Alan Woodward
>            Assignee: Alan Woodward
>            Priority: Minor
>         Attachments: LUCENE-7736.patch, LUCENE-7736.patch, LUCENE-7736.patch, LUCENE-7736.patch
> We have a number of ValueSource implementations that expose IndexReader stats (numDocs,
termFreq, etc).  We should re-implement these as DoubleValuesSources, allowing them to be
used in FunctionScoreQuery, etc.

This message was sent by Atlassian JIRA

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message