You are viewing a plain text version of this content. The canonical link for it is here.
Posted to java-user@lucene.apache.org by Joseph MarkAnthony <mr...@comcast.net> on 2011/08/29 20:54:08 UTC
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-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-user-help@lucene.apache.org
Re: No subsearcher in Lucene 3.3?
Posted by "Devon H. O'Dell" <de...@gmail.com>.
2011/8/29 Uwe Schindler <uw...@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: uwe@thetaphi.de
>
>
>> -----Original Message-----
>> From: Joseph MarkAnthony [mailto:mrjama@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-unsubscribe@lucene.apache.org
>> For additional commands, e-mail: java-user-help@lucene.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-user-unsubscribe@lucene.apache.org
> For additional commands, e-mail: java-user-help@lucene.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: java-user-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-user-help@lucene.apache.org
Re: No subsearcher in Lucene 3.3?
Posted by KARTHIK SHIVAKUMAR <ns...@gmail.com>.
HI
Long time ago I used to do the same ...
I used to name the merger Index unique names ......so at run time If the
Query returned from 1STMERGER then the path relevant to 1STMEGEr will be
used.
similarly U NEED NOT STORE A NEW COLUMN FOR THIS SAKE......
1MERGER = /temp/MERGER1 Finally the PATH OF INDEX SEARCH IS
C:/TEMP/MERGER1
1MERGER = /temp/MERGER2 Finally the PATH OF INDEX SEARCH IS
D:/TEMP/MERGER2
HOPE THIS HELPS
WITH REGARDS
KARTHIK
On Tue, Aug 30, 2011 at 9:59 PM, Joe MA <mr...@comcast.net> wrote:
>
> Thanks for the replies. Here is why I need the subreader (or subsearcher
> in earlier Lucene versions):
>
> I have multiple collections of documents, say broken out by years (it's
> more complex than this, but this illustrates the use case):
>
> Collection1 >>> D:/some folder/2009/*.pdf
> (lots of PDF files)
> Collection2 >>> D:/another folder/2010/*.pdf
> (lots of different PDF files)
>
> And so forth. So in the example above, I would have two indicies, one for
> each year. When I index, I store the *relative* path of each document as
> a field. For example, 'link:2009/file1.pdf' or 'link2010/file1.pdf' etc .
> I do not store the full path to the files in the index. This has a huge
> advantage because we can move the documents to another file system or server
> or path without rebuilding the index. I stored the required base path to
> the documents in each collection in a database, external to the collection.
> For example, in the above example, Collection1 would have a base path of
> "D:/some folder/". Therefore, to actually access a document referenced
> in a collection, you would concat base_path retrieved from the database to
> the "link" field retrieved from the collection. I would think this is a
> very common approach.
>
> 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.
>
> I guess a real simple solution is just to store a new field with each
> document uniquely identifying which collection. So in the example above, I
> could create a new field "foreign_key_index" for each document which would
> be "Collection1" or "Collection2" respectively. This would surely work, but
> it would break backwards compatibility of my system and would require me to
> rebuild every collection. Also seems pretty extensive for something so
> simple.
>
> If there is another way to do this, please advise. Thanks in advance and
> much appreciated.
>
> - JMA
>
>
>
> -----Original Message-----
> From: Uwe Schindler [mailto:uwe@thetaphi.de]
> Sent: Monday, August 29, 2011 8:05 PM
> To: java-user@lucene.apache.org
> Subject: RE: No subsearcher in Lucene 3.3?
>
> 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).
>
> Uwe
>
> -----
> Uwe Schindler
> H.-H.-Meier-Allee 63, D-28213 Bremen
> http://www.thetaphi.de
> eMail: uwe@thetaphi.de
>
>
> > -----Original Message-----
> > From: Joseph MarkAnthony [mailto:mrjama@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-unsubscribe@lucene.apache.org
> > For additional commands, e-mail: java-user-help@lucene.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-user-unsubscribe@lucene.apache.org
> For additional commands, e-mail: java-user-help@lucene.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-user-unsubscribe@lucene.apache.org
> For additional commands, e-mail: java-user-help@lucene.apache.org
>
>
--
*N.S.KARTHIK
R.M.S.COLONY
BEHIND BANK OF INDIA
R.M.V 2ND STAGE
BANGALORE
560094*
RE: No subsearcher in Lucene 3.3?
Posted by Joe MA <mr...@comcast.net>.
Thanks I will give this a try, seems like it should work for my case.
-----Original Message-----
From: Uwe Schindler [mailto:uwe@thetaphi.de]
Sent: Tuesday, August 30, 2011 3:53 PM
To: java-user@lucene.apache.org
Subject: RE: No subsearcher in Lucene 3.3?
Hi,
Use ReaderUtil from o.a.l.util package that does the recursive traversal of
the reader tree. It has methods to solve this problems. You can cache the
int[] start array that contains the starting document ids for each
subreader. This makes it possible to use standard TopDocs based search
without Collectors (which should not be required for your case) to remap the
document ids.
As for this issue you are not interested in stepping recursively into the
reader tree to the lowest level (as non-optimized subindexes will also
expand to multiple readers), so the only thing you would like to know is: on
which direct subreader of MultiReader you are interested. For a quick
lookup, an approach might be to iterate *once* before search over the direct
subreaders of the MultiReader (without recursion), and sum up the maxDoc()
(not numDocs!) return values. For each subreader (starting with 0) put the
sum into a TreeMap (!!!) with the target index name or whatever you need to
identify the subreader. You can then lookup the docid from the TopDocs
object using TreeMap.floorEntry(docId).getValue() (Java 6 only).
Uwe
-----
Uwe Schindler
H.-H.-Meier-Allee 63, D-28213 Bremen
http://www.thetaphi.de
eMail: uwe@thetaphi.de
> -----Original Message-----
> From: Devon H. O'Dell [mailto:devon.odell@gmail.com]
> Sent: Tuesday, August 30, 2011 8:04 PM
> To: java-user@lucene.apache.org
> Subject: Re: No subsearcher in Lucene 3.3?
>
> 2011/8/30 Joe MA <mr...@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-unsubscribe@lucene.apache.org
> For additional commands, e-mail: java-user-help@lucene.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: java-user-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-user-help@lucene.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: java-user-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-user-help@lucene.apache.org
RE: No subsearcher in Lucene 3.3?
Posted by Uwe Schindler <uw...@thetaphi.de>.
Hi,
Use ReaderUtil from o.a.l.util package that does the recursive traversal of
the reader tree. It has methods to solve this problems. You can cache the
int[] start array that contains the starting document ids for each
subreader. This makes it possible to use standard TopDocs based search
without Collectors (which should not be required for your case) to remap the
document ids.
As for this issue you are not interested in stepping recursively into the
reader tree to the lowest level (as non-optimized subindexes will also
expand to multiple readers), so the only thing you would like to know is: on
which direct subreader of MultiReader you are interested. For a quick
lookup, an approach might be to iterate *once* before search over the direct
subreaders of the MultiReader (without recursion), and sum up the maxDoc()
(not numDocs!) return values. For each subreader (starting with 0) put the
sum into a TreeMap (!!!) with the target index name or whatever you need to
identify the subreader. You can then lookup the docid from the TopDocs
object using TreeMap.floorEntry(docId).getValue() (Java 6 only).
Uwe
-----
Uwe Schindler
H.-H.-Meier-Allee 63, D-28213 Bremen
http://www.thetaphi.de
eMail: uwe@thetaphi.de
> -----Original Message-----
> From: Devon H. O'Dell [mailto:devon.odell@gmail.com]
> Sent: Tuesday, August 30, 2011 8:04 PM
> To: java-user@lucene.apache.org
> Subject: Re: No subsearcher in Lucene 3.3?
>
> 2011/8/30 Joe MA <mr...@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-unsubscribe@lucene.apache.org
> For additional commands, e-mail: java-user-help@lucene.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: java-user-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-user-help@lucene.apache.org
Re: No subsearcher in Lucene 3.3?
Posted by "Devon H. O'Dell" <de...@gmail.com>.
2011/8/30 Joe MA <mr...@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-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-user-help@lucene.apache.org
RE: No subsearcher in Lucene 3.3?
Posted by Joe MA <mr...@comcast.net>.
Thanks for the replies. Here is why I need the subreader (or subsearcher in earlier Lucene versions):
I have multiple collections of documents, say broken out by years (it's more complex than this, but this illustrates the use case):
Collection1 >>> D:/some folder/2009/*.pdf (lots of PDF files)
Collection2 >>> D:/another folder/2010/*.pdf (lots of different PDF files)
And so forth. So in the example above, I would have two indicies, one for each year. When I index, I store the *relative* path of each document as a field. For example, 'link:2009/file1.pdf' or 'link2010/file1.pdf' etc . I do not store the full path to the files in the index. This has a huge advantage because we can move the documents to another file system or server or path without rebuilding the index. I stored the required base path to the documents in each collection in a database, external to the collection. For example, in the above example, Collection1 would have a base path of "D:/some folder/". Therefore, to actually access a document referenced in a collection, you would concat base_path retrieved from the database to the "link" field retrieved from the collection. I would think this is a very common approach.
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.
I guess a real simple solution is just to store a new field with each document uniquely identifying which collection. So in the example above, I could create a new field "foreign_key_index" for each document which would be "Collection1" or "Collection2" respectively. This would surely work, but it would break backwards compatibility of my system and would require me to rebuild every collection. Also seems pretty extensive for something so simple.
If there is another way to do this, please advise. Thanks in advance and much appreciated.
- JMA
-----Original Message-----
From: Uwe Schindler [mailto:uwe@thetaphi.de]
Sent: Monday, August 29, 2011 8:05 PM
To: java-user@lucene.apache.org
Subject: RE: No subsearcher in Lucene 3.3?
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).
Uwe
-----
Uwe Schindler
H.-H.-Meier-Allee 63, D-28213 Bremen
http://www.thetaphi.de
eMail: uwe@thetaphi.de
> -----Original Message-----
> From: Joseph MarkAnthony [mailto:mrjama@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-unsubscribe@lucene.apache.org
> For additional commands, e-mail: java-user-help@lucene.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: java-user-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-user-help@lucene.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: java-user-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-user-help@lucene.apache.org
RE: No subsearcher in Lucene 3.3?
Posted by Uwe Schindler <uw...@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).
Uwe
-----
Uwe Schindler
H.-H.-Meier-Allee 63, D-28213 Bremen
http://www.thetaphi.de
eMail: uwe@thetaphi.de
> -----Original Message-----
> From: Joseph MarkAnthony [mailto:mrjama@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-unsubscribe@lucene.apache.org
> For additional commands, e-mail: java-user-help@lucene.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: java-user-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-user-help@lucene.apache.org
Re: No subsearcher in Lucene 3.3?
Posted by "Devon H. O'Dell" <de...@gmail.com>.
2011/8/29 Joseph MarkAnthony <mr...@comcast.net>:
> 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?
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.
--dho
> Thanks in advance,
> JMA
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-user-unsubscribe@lucene.apache.org
> For additional commands, e-mail: java-user-help@lucene.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: java-user-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-user-help@lucene.apache.org