[
https://issues.apache.org/jira/browse/LUCENE-2831?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12974726#action_12974726
]
Yonik Seeley commented on LUCENE-2831:
--------------------------------------
{quote}I think we should add the sub-ReaderInfos too, so the tree is
doubly-linked?
{quote}
Yeah, sounds like a good idea. Solr currently has this functionality via
SolrIndexReader (all lucene readers in the tree are wrapped on every reopen),
and every SolrIndexReader has the list of children, and a parent pointer. So
this is turning into the same thing, just with a parallel data structure (which
mirrors the actual reader tree) instead of wrapping.
{quote} Actually I think we can and should store this in IndexReader?
But, only the top-level reader is allowed to hold ReaderInfo for all
subs it [recurisvely] contains.
{quote}
A top level reader may also be a sub-reader of another top level reader... so
it doesn't seem
like we can make that restriction, and any ReaderInfo stored on an IndexReader
would only be valid
in some contexts. Think about simply trying to walk up to the top level
reader, or using "offset"
or "ord' which vary depending on the top-level reader.
And if that info is passed down to weight() and scorer() anyway, what's the
point of storing it on IR?
I guess if we made the restriction that things that vary depending on top-level
reader should be avoided
in ReaderInfo if obtained directly from an IndexReader, it would be OK. But
that's a severe and strange restriction.
We can try approaching it from the other direction too... what is gained or
made easier by storing ReaderInfo on IR? What are the usecases?
> 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: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
