[
https://issues.apache.org/jira/browse/LUCENE-2831?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12975745#action_12975745
]
Simon Willnauer commented on LUCENE-2831:
-----------------------------------------
bq. I'm confused - there'd be no restriction with this approach? Ie it would
allow for a sub that's shared in different top readers.
I think what yonik it saying it that you can not be sure that the
topLevelReader is a TopLevelReader since it could have yet another parent.
This will always be true and essentially only well defined in the context of an
IndexSearcher. IndexSearcher takes an arbitrary IndexReader as a topLevel and
this will be the one for this IS context. The same IR could be a sub-reader in
a different context though.
I'm tend to lean towards holding ReaderInfo on IndexSearcher rather than on
IndexReader. It is really an information that 100% depends on a context which
is given by IS. IS also defines the context for Query#weigth / createWeight and
Weight ctors and with LUCENE-2837 we can eventually rely on the given Searcher
is an IS.
bq. Another thing to think about is if this should be unified with the very
similar ReaderUtil.Slice
I agree this should be easy to obtain.
bq. SolrIndexReader could be removed altogether if this is solved correctly -
it's only real purpose was really to solve this context problem.
yeah this makes sense. I didn't look into it too deep during the first patch.
I think we should give Yoniks full ReaderInfo a go an create it only in IS.
This might make some Solr classes go away too and reduce complexity. I will go
ahead and work on a new patch soon.
> Revise Weight#scorer & Filter#getDocIdSet API to pass Readers context
> ---------------------------------------------------------------------
>
> Key: LUCENE-2831
> URL: https://issues.apache.org/jira/browse/LUCENE-2831
> Project: Lucene - Java
> Issue Type: Improvement
> Components: Search
> Affects Versions: 4.0
> Reporter: Simon Willnauer
> Assignee: Simon Willnauer
> Fix For: 4.0
>
> Attachments: LUCENE-2831.patch
>
>
> Spinoff from LUCENE-2694 - instead of passing a reader into Weight#scorer(IR,
> boolean, boolean) we should / could revise the API and pass in a struct that
> has parent reader, sub reader, ord of that sub. The ord mapping plus the
> context with its parent would make several issues way easier. See
> LUCENE-2694, LUCENE-2348 and LUCENE-2829 to name some.
--
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: [email protected]
For additional commands, e-mail: [email protected]
