[
https://issues.apache.org/jira/browse/LUCENE-1749?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12737509#action_12737509
]
Mark Miller commented on LUCENE-1749:
-------------------------------------
{quote}I don't really follow you on this (i need to take a look at your
proposed fix) .. i'm not suggesting we push the whole explain down to the
subreader, just that when the explain method wants to get hte FieldCache value
for a doc, it should fetch the FieldCache for the SegmentReader the doc is in -
so it gets the exact same value (and same FieldCache entry) as the scoring code
did when it scores the document. (or maybe i'm completley missunderstanding how
these classes were reimplimented to use segment based field caches){quote}
The way the per segment stuff went, we don't push down to the sub readers for
the fieldcache per say - we just search each sub reader separately - so per
reader fieldcache is just kind of a side effect. Then the top level reader is
still used for things like stats and explain.
I switched the explain for the offending stuff (custom/valuesource) to use a
DocValues class that does push down to each subreader for the fieldcache though
(while everything else still uses the top reader) - its in the scorer, so I
added a switch to push down to subreaders for fieldcache access or not - only
explain pushes down, while regular scoring doesn't (regular scoring will be
working per sub reader anyway, because they are searched one at a time).
I can merge up the patches.
> 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
>
>
> 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
