lucene-java-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Devon H. O'Dell" <>
Subject Re: No subsearcher in Lucene 3.3?
Date Tue, 30 Aug 2011 18:03:34 GMT
2011/8/30 Joe MA <>:
> When searching a single collection, no problem.  But if I want to search the two collections
at the same time, I need to know which collection the hit came from so I can retrieve the
base_path from the database.  These base_paths can be different.  As mentioned, this was
trivial in Lucene 1.x and 2.x as I just grabbed the subsearcher from the result, which would
for example return a 1 or 2 indicating which of the two collections the result came from.
 Then I can build the path to the file.  In other words, subsearcher gave me the foreign
key I needed to map to additional external information associated with each index during a
multisearch.  That is now gone in Lucene 3.3.

You could use the suggestion I made of doing the loop over the
IndexReader subReaders (recursively until you get to the
SegmentReaders) and use a HashMap<SegmentReader, String> (or similar
container structure) to associate the segments to a path. It sounds
like your application doesn't reopen indexes with much frequency,
which is good: you will need to regenerate this map any time you
reopen your indexes.

When collector.setNextReader is called, you can simply get (at that
point) the String associated with the particular SegmentReader you're
working with. Then, every time Collector.collect is called, you can
tack that on to whatever data structure you're using to get at your
documents. It doesn't have to be high memory overhead if you make sure
the strings are interned.

Perhaps Uwe or other Lucene devs have better ideas for approaching
this; they often do :)


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message