lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Michael McCandless (JIRA)" <j...@apache.org>
Subject [jira] Commented: (LUCENE-1749) FieldCache introspection API
Date Tue, 04 Aug 2009 18:28:14 GMT

    [ https://issues.apache.org/jira/browse/LUCENE-1749?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12739080#action_12739080
] 

Michael McCandless commented on LUCENE-1749:
--------------------------------------------

bq. Right - that code was well tested and exercised via MultiSearcher in the past (all idf
values had to come from Weight to avoid getting idfs per sub-searcher).

Ahh right.

bq. One thing that's missing for explain() is that there is no way to get "df" as opposed
to "idf" from the Weight.

But this only affects the "atomic" queries, right?  So eg TermWeight
could simply hold onto this value and then use it during explain.
Hmm... though TermQuery's ctor doesn't get the df directly, because it
calls similarity.idf(term, searcher).  I don't really like making a
separate additional call to docFreq.

How about, for queries that need to go and look up docFreq, their
QueryWeight impls simply hold onto the [top-level] IndexSearcher that
had been passed to their ctor, and then do the docFreq call against
that, if explain is invoked?

bq. Right.. it doesn't belong there. Perhaps deprecate and remove from the Scorer base in
3.0? (since one can't reliably call it now anyway).

+1

Hoss/Mark do you want to fold it in to the patch, here?  Or I can open
a new issue?


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


Mime
View raw message