[
https://issues.apache.org/jira/browse/LUCENE-1821?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12744854#action_12744854
]
Tim Smith commented on LUCENE-1821:
-----------------------------------
bq. I'm not saying we should make it impossible for you to do this - but I
don't think we should open a path for scorers to reconstruct multi-reader
virtual ids. I don't think a Scorer should know or care why type of IndexReader
it is working with.
i disagree with that, i think the APIs should make it clear whether you are
working with a sub reader or a top level reader
if a Scorer is given an IndexReader, it should have the same ability to
reconstruct the "client facing" docid in the same manner as the Collector
interface provides in order to provide a consistent interface between
Collectors and Scorers
This reconstruction should be documented as "advanced", however it should still
be available
Whereever an IndexReader is exposed in API calls, it should be possible to walk
the IndexReader's parent IndexReaders until you get the top level reader in
order to have the full context of that IndexReader. This walking should only be
done at "init" time (Scorer construction/Collector setScorer(), and so on
depending on need of the application, but it should be possible (ideally
without doing nasty things))
> Weight.scorer() not passed doc offset for "sub reader"
> ------------------------------------------------------
>
> Key: LUCENE-1821
> URL: https://issues.apache.org/jira/browse/LUCENE-1821
> Project: Lucene - Java
> Issue Type: Bug
> Components: Search
> Affects Versions: 2.9
> Reporter: Tim Smith
>
> Now that searching is done on a per segment basis, there is no way for a
> Scorer to know the "actual" doc id for the document's it matches (only the
> relative doc offset into the segment)
> If using caches in your scorer that are based on the "entire" index (all
> segments), there is now no way to index into them properly from inside a
> Scorer because the scorer is not passed the needed offset to calculate the
> "real" docid
> suggest having Weight.scorer() method also take a integer for the doc offset
> Abstract Weight class should have a constructor that takes this offset as
> well as a method to get the offset
> All Weights that have "sub" weights must pass this offset down to created
> "sub" weights
--
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
