[
https://issues.apache.org/jira/browse/LUCENE-2831?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12977719#action_12977719
]
Michael McCandless commented on LUCENE-2831:
--------------------------------------------
Looks good Simon! Random comments...
Maybe rename AtomicContext -> AtomicReaderContext? And same for
CompositeContext?
Should Filter.getDocIDSet take an AtomicReaderContext? We don't have
to do that in this patch, though... this patch is a big enough first
step!
Leafes -> Leaves
Maybe IR.getTopReaderContext() instead of IR.topLevelReaderContext()?
(Or .getRootReaderContext()?).
I agree this should eventually subsume
.getSequentialReaders... though, we probably should change IR base
method to return null not throw UOE, if so (until we succeed in
statically typing composite vs atomic readers...).
I think we can change the expert IndexSearcher ctor that takes the
forced subReaders to instead take a root ReaderContext? In fact,
maybe we can remove it altogether? It was added to avoid the
"relatively costly" gatherSubReaders that IS does if you just pass it
an IR, but, we are now fixing that w/ this issue, by having IR cache
the root ReaderContext...
If we did that could we go back to having QueryWrapperFilter just make
an IndexSearcher?
Do we really need forceLeafs()? Can't QueryWrapperFilter make a
MultiReader holding just its atomic IR and pass that to IS? And then
we can remove the AtomicContext ctor that takes a "naked" atomic
reader?
QueryWrapperFilter's WeightOnlyearcher should be WeightOnlySearcher.
> 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, 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: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
