[
https://issues.apache.org/jira/browse/LUCENE-1749?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12738100#action_12738100
]
Michael McCandless commented on LUCENE-1749:
--------------------------------------------
bq. That was my first thought... but it would probably break more than it
helped right now (by exposing more limitations) - for example idf in
TermWeight.explain()
Ugh, you're right.
I think It shouldn't be doing that? Ie, a Weight instance should
"capture" all stats needed from the top-level searcher, on creation,
and then when we ask for a scorer or an explain (or other future
things that take an IndexReader) we should always pass in a single
segment reader. This way we don't have to duplicate the "go find the
right sub-reader" in many places.
It's interesting that we didn't (I think?) have a similar problem w/
scorer when we switched to passing it the sub-reader.
bq. I'll leave the 'explain at multiple levels' for another issue
It looks like it's up to each query, which level does what.
IndexSearcher's explain always calls Weight.explain, but then some
Query impls (eg BooleanQuery) do everything in Weight.explain, while
others (eg TermQuery, PhraseQuery) do some work in Weight.explain and
some in the scorer.
I guess this makes sense: "atomic" Queries (TermQuery, PhraseQuery)
will need to fire up a scorer since there's real work to be done to
see the specifics of how that doc was matched. Whereas BooleanQuery simply
"glues" together other queries so it doesn't need to forward to its
[many] scorers.
So the only odd thing is why explain is part of Scorer base
class... seems like the method could/should live "privately" to only
those queries that need it.
But I agree let's leave this be for now...
> FieldCache introspection API
> ----------------------------
>
> Key: LUCENE-1749
> URL: https://issues.apache.org/jira/browse/LUCENE-1749
> Project: Lucene - Java
> Issue Type: Improvement
> Components: Search
> Reporter: Hoss Man
> Priority: Minor
> Fix For: 2.9
>
> Attachments: fieldcache-introspection.patch,
> LUCENE-1749-hossfork.patch, LUCENE-1749.patch, LUCENE-1749.patch,
> LUCENE-1749.patch, LUCENE-1749.patch, LUCENE-1749.patch, LUCENE-1749.patch,
> LUCENE-1749.patch, LUCENE-1749.patch, LUCENE-1749.patch, LUCENE-1749.patch
>
>
> FieldCache should expose an Expert level API for runtime introspection of the
> FieldCache to provide info about what is in the FieldCache at any given
> moment. We should also provide utility methods for sanity checking that the
> FieldCache doesn't contain anything "odd"...
> * entries for the same reader/field with different types/parsers
> * entries for the same field/type/parser in a reader and it's subreader(s)
> * etc...
--
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-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-dev-h...@lucene.apache.org
