lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Yonik Seeley (JIRA)" <>
Subject [jira] Commented: (LUCENE-2831) Revise Weight#scorer & Filter#getDocIdSet API to pass Readers context
Date Thu, 23 Dec 2010 20:42:47 GMT


Yonik Seeley commented on LUCENE-2831:

{quote}I think we should add the sub-ReaderInfos too, so the tree is

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. 

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
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:
>             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:
For additional commands, e-mail:

View raw message