2011/8/29 Uwe Schindler <u...@thetaphi.de>: > Why do you need to know the subreader? If you want to get the document's > stored fields, use the MultiReader. > > If you really want to know the subreader, use this: > http://lucene.apache.org/java/3_3_0/api/core/org/apache/lucene/util/ReaderUtil.html#subReader(int, > org.apache.lucene.index.IndexReader) > > But this is "somewhat slow", so don’t use in inner loops. > > Devon suggested: >> If I'm understanding your question correctly, in the Collector, you are told >> which IndexReader you are working with when the setNextReader method is >> called. Hopefully that helps. > > This does not work as expected, because the Collector gets the lowest level > readers, which are in fact sub-sub-readers (as each single IndexReader > contains itself of more "SegmentReaders", unless you have optimized > sub-indexes).
Sure, I just had no idea what was trying to be accomplished. You can work backwards constructing some kind of data structure that loops over the subreaders when you open the indexes and have a map that points from subreader -> main reader. That's really not such a big deal if you do it once, but still has overhead if you're updating a lot and are doing NRT stuff. Anyway, you're right, I phrased that rather poorly. And I don't have any idea what you'd do with that other than maybe some caching stuff. --dho > Uwe > > ----- > Uwe Schindler > H.-H.-Meier-Allee 63, D-28213 Bremen > http://www.thetaphi.de > eMail: u...@thetaphi.de > > >> -----Original Message----- >> From: Joseph MarkAnthony [mailto:mrj...@comcast.net] >> Sent: Monday, August 29, 2011 8:54 PM >> To: java-user@lucene.apache.org >> Subject: No subsearcher in Lucene 3.3? >> >> Greetings, >> In the past (Lucene version 2.x) I successfully used >> MultiSearcher.subsearcher() to identify the searchable within a MultiSearcher >> to which a hit belonged. >> >> In moving to Lucene 3.3, MultiSearcher is now deprecated, and I am trying to >> create a standard IndexSearcher over a MultiReader. I haven't gotten this to >> work yet but it appears to be the correct approach. However, I cannot find >> any >> corresponding "subsearcher" method that could identify which subreader is the >> one that finds the hit. >> >> For example, it used to be straightforward: >> >> Create a MultiSearcher over several Searchables, and call >> MultiSearcher.subsearcher to get the searchable that holds each search hit. >> >> Now, I am creating an IndexSearcher over a MultiReader, which is created over >> an array of IndexReaders. So when I get a hit, what's the best way to >> determine which of the several subReaders the hit came from? >> >> Thanks in advance, >> JMA >> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: java-user-unsubscr...@lucene.apache.org >> For additional commands, e-mail: java-user-h...@lucene.apache.org > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: java-user-unsubscr...@lucene.apache.org > For additional commands, e-mail: java-user-h...@lucene.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: java-user-unsubscr...@lucene.apache.org For additional commands, e-mail: java-user-h...@lucene.apache.org
