lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Tim Smith (JIRA)" <j...@apache.org>
Subject [jira] Commented: (LUCENE-1821) Weight.scorer() not passed doc offset for "sub reader"
Date Wed, 19 Aug 2009 03:11:14 GMT

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


Mime
View raw message