2011/8/30 Joe MA <mrj...@comcast.net>: > 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 :) --dho --------------------------------------------------------------------- To unsubscribe, e-mail: java-user-unsubscr...@lucene.apache.org For additional commands, e-mail: java-user-h...@lucene.apache.org
