[
https://issues.apache.org/jira/browse/LUCENE-1749?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12737424#action_12737424
]
Hoss Man commented on LUCENE-1749:
----------------------------------
Quick responses to some other comments...
bq. I chose a different route after considering both
i trust you to make the right call, just thought i'd point it out in case you
hadn't though of it.
bq. If you push explain to the sub readers, you will get why it scored as it
did for each subreader - not one top level explain
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)
bq. This issue was a fantastic idea by the way!
yeah ... i was pretty out of the loop on all the "push sorting down into the
segment" discussion, but when i noticed yonik pointing out all the ways solr's
fieldcache usage was going to explode if we didn't change it it occured to me
that this would probably be a big problem for anyone doing non-trivial stuff
with Lucene, so it would be nice to have a way to toruble shoot it (i also had
very little faith in Lucene-Java's test coverage since we only have unit tests
that verify "correct" behavior when we make changes -- but nothing sanity
checks how that behavior happened (at least: not untill 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
>
>
> 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
