Hi,
MultiSearcher was deprecated in Lucene 3.1 and removed in Lucene 4.0. Use a
MultiReader on top of a set of IndexReaders and construct a simple
IndexSearcher using the MultiReader. See also the Javadocs how to do this.
Before:
MultiSearcher( IndexSearcher(IndexReader), IndexSearcher(I
@lucene.apache.org
Subject: Re: MultiSearcher query with Sort option
Hi,
I just realized it was a bug in my code.
On a related note, is it possible to Sort based on reverse index
order ?
Thanks,
~preetham
Uwe Schindler wrote:
Hallo Preetham,
never heard of this. What Lucene version do you use
-
From: Preetham Kajekar [mailto:preet...@cisco.com]
Sent: Friday, April 10, 2009 11:27 AM
To: java-user@lucene.apache.org
Subject: Re: MultiSearcher query with Sort option
Hi,
I just realized it was a bug in my code.
On a related note, is it possible to Sort based on reverse index order ?
Thanks
de
> eMail: u...@thetaphi.de
>
>> -Original Message-
>> From: Preetham Kajekar [mailto:preet...@cisco.com]
>> Sent: Friday, April 10, 2009 11:27 AM
>> To: java-user@lucene.apache.org
>> Subject: Re: MultiSearcher query with Sort option
>>
>> Hi,
&
://www.thetaphi.de
eMail: u...@thetaphi.de
> -Original Message-
> From: Preetham Kajekar [mailto:preet...@cisco.com]
> Sent: Friday, April 10, 2009 11:27 AM
> To: java-user@lucene.apache.org
> Subject: Re: MultiSearcher query with Sort option
>
> Hi,
> I just realized it was
Hi,
I just realized it was a bug in my code.
On a related note, is it possible to Sort based on reverse index order ?
Thanks,
~preetham
Uwe Schindler wrote:
Hallo Preetham,
never heard of this. What Lucene version do you use?
To check out, try the search in andifferent way:
Combine the two ind
Hallo Preetham,
never heard of this. What Lucene version do you use?
To check out, try the search in andifferent way:
Combine the two indexes not into a MultiSearcher, instead open an
IndexReader for both indexes and combine both readers to a MultiReader. This
MultiReader can be used like a conven
Not out of the box, but it's fairly trivial to copy multisesscher and
modify it so that a different query goes to each suvsearcher.
- Mark
On Nov 8, 2008, at 5:45 AM, "Shishir Jain" <[EMAIL PROTECTED]>
wrote:
Hi,
Doc1: Field1, Field2
Doc2: Field1, Field2
If I create Index such that Fie
Any commets are suggestions are greatly appreciated.
Regards
Ganesh
- Original Message -
From: "Ganesh" <[EMAIL PROTECTED]>
To:
Sent: Thursday, October 23, 2008 3:45 PM
Subject: Re: Multisearcher will maintain index order sorting?
Multisearcher after performing
esh
- Original Message -
From: "Hadi Forghani" <[EMAIL PROTECTED]>
To:
Sent: Thursday, October 23, 2008 3:25 PM
Subject: Re: Multisearcher will maintain index order sorting?
because when you want to find X of second index, shoud pass docId=3 to
MultiSearcher and MultiSearcher
3,X
> 1,X Y
> 4,X Y
> 2,X Z
> 5,X Z
>
> But it should be in the order of 0,1,2,3,4,5. Could anyone explain why?
>
> Regards
> Ganesh
>
> - Original Message - From: "Ganesh" <[EMAIL PROTECTED]>
> To:
> Sent: Thursday, Octobe
. Could anyone explain why?
Regards
Ganesh
- Original Message -
From: "Ganesh" <[EMAIL PROTECTED]>
To:
Sent: Thursday, October 23, 2008 1:37 PM
Subject: Re: Multisearcher will maintain index order sorting?
Multisearcher and ParallelMultiSearcher, when requested to sort
Multisearcher and ParallelMultiSearcher, when requested to sort on doc
(indexed order), it merges the result by docID of each DB.
Regards
Ganesh
- Original Message -
From: "Paul Smith" <[EMAIL PROTECTED]>
To:
Sent: Thursday, October 23, 2008 10:57 AM
Subject: Re: Mu
On 23/10/2008, at 4:20 PM, Ganesh wrote:
My Index DB is having 10 million records and it will grow to 30
million. Currently I am using millisecond timestamp and the RAM
cosumption is more. I will change the resolution to minute. I am
using 2 searcher objects refreshing each other every min
Erick Erickson" <[EMAIL PROTECTED]>
To:
Sent: Tuesday, October 21, 2008 8:18 PM
Subject: Re: Multisearcher will maintain index order sorting?
You say the timestamp sort is taking lots of RAM, which leads
me to ask "what resolution are you using and do you need
that great a resoluti
You say the timestamp sort is taking lots of RAM, which leads
me to ask "what resolution are you using and do you need
that great a resolution"?
As I understand it, sorting is sensitive to the number of unique
terms, so if you're storing millisecond timestamps you have a
whole lot more terms than
: The idea was to override TopFieldDocCollector to do the sorting etc. and only
: load the full document for those we need to display. But, I haven't found an
: easy way to use TopFieldDocCollector (FieldSortedHitQueue etc.) with
: MultiSearcher.
I don't understand this statement ... i mean, i ha
lr - Nutch
- Original Message
From: "[EMAIL PROTECTED]" <[EMAIL PROTECTED]>
To: java-user@lucene.apache.org
Sent: Saturday, March 8, 2008 3:32:56 PM
Subject: RE: MultiSearcher to overcome the Integer.MAX_VALUE limit
> Right... but trust me, you really wouldn't want to.
> Right... but trust me, you really wouldn't want to. You need
> distributed search at that level anyway.
Hm, 2 billion small docs are not so much.
Why do I need distributed search and what exactly do you means with
distributed search? Multiple IndexSearchers? Multiple processes? Multiple
machin
On Sat, Mar 8, 2008 at 2:06 PM, <[EMAIL PROTECTED]> wrote:
> Does this mean that I cannot search indexes with more than 2 billion docs at
> all with a single IndexSearcher?
Right... but trust me, you really wouldn't want to. You need
distributed search at that level anyway.
-Yonik
--
Does this mean that I cannot search indexes with more than 2 billion docs at
all with a single IndexSearcher?
> -Original Message-
> From: Mark Miller [mailto:[EMAIL PROTECTED]
> Sent: Samstag, 8. März 2008 18:57
> To: java-user@lucene.apache.org
> Subject: Re: MultiSearc
Random text can often be pretty slow when done per word.
I think you will have to modify the MultiSearcher a bit. The
MultiSearcher takes a global id space and converts to and from an
individual Searcher id space. The MultiSearcher's id space is limited to
an int as well, but I think if you ch
On Fri, 2008-03-07 at 00:03 +0100, Ray wrote:
> I am currently running a small random text indexer with 400 docs/second.
> It will reach 2 billion in around 45 days.
If you are just doing it to test large indexes (in terms of document
count), then you need to look into your index-generation code.
s.
>
> I really hope you all who are saying 2 billion docs
> will bring lucene to its knees are wrong...
>
> Ray.
>
> - Original Message -
> From: "Erick Erickson" <[EMAIL PROTECTED]>
> To:
> Sent: Thursday, March 06, 2008 10:40 PM
> Subjec
you all who are saying 2 billion docs
will bring lucene to its knees are wrong...
Ray.
- Original Message -
From: "Erick Erickson" <[EMAIL PROTECTED]>
To:
Sent: Thursday, March 06, 2008 10:40 PM
Subject: Re: MultiSearcher to overcome the Integer.MAX_VALUE limit
We
Well, I'm not sure. But any index, even one split amongst many nodes
is going to have some interesting performance characteristics if you
have over 2 billion documents So I'm not sure it matters ...
What problem are you really trying to solve? You'll probably get
more meaningful answers if you
Wow Mark, quite the hint. Thanks so much.
Spencer
-Original Message-
From: Mark Miller [mailto:[EMAIL PROTECTED]
Sent: August 14, 2007 12:07 PM
To: java-user@lucene.apache.org
Subject: Re: MultiSearcher with mulitple filter
Here is a hint:
package org.apache.lucene.search;
import
Here is a hint:
package org.apache.lucene.search;
import java.io.IOException;
/**
* Implements search over a set of Searchables using
multiple filters.
*/
public class MultiFilterMultiSearcher extends MultiSearcher {
public MultiFilterMultiSearcher(Searchable[] searchables)
throws
That works, thanks.
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Yonik Seeley
Sent: Tuesday, June 19, 2007 9:57 AM
To: java-user@lucene.apache.org
Subject: Re: MultiSearcher holds on to index - optimization not one segment
On 6/19/07, Beard, Brian
On 6/19/07, Beard, Brian <[EMAIL PROTECTED]> wrote:
This may seem like a naïve question - since the garbage collection is not
enforcable, is it possible to send a flag to the IndexReader to give this up
once the reader is no longer needed?
You call close() on the IndexReader (or the IndexSear
: Tuesday, June 19, 2007 9:06 AM
To: java-user@lucene.apache.org
Subject: Re: MultiSearcher holds on to index - optimization not one segment
On 6/19/07, Beard, Brian <[EMAIL PROTECTED]> wrote:
> The problem I'm having is once the MultiSearcher is open, it holds on to
> t
On 6/19/07, Beard, Brian <[EMAIL PROTECTED]> wrote:
The problem I'm having is once the MultiSearcher is open, it holds on to
the index file
An IndexReader holds open the files... this is a feature. Not holding
the file open would mean that the index would actively change while
being searched.
Israel, I don't really know much about MultiSearcher, but just to clarify:
are you saying that the change you have works ok, as long as people are
also using hte patch in LUCENE-789 (which will be in 2.2) or are you
saying that the change you tried doesn't work when using a custom
similarity, for
In case anyone was interested, making the change I described surfaced a bug
that causes the custom similarity to not work.
There is a patch:
https://issues.apache.org/jira/browse/LUCENE-789
On 5/29/07, Israel Tsadok <[EMAIL PROTECTED]> wrote:
Hi,
I am developing a distributed index, using Mult
Original Message-
From: Doron Cohen [mailto:[EMAIL PROTECTED]
Sent: Tuesday, April 24, 2007 3:39 PM
To: java-user@lucene.apache.org
Subject: Re: MultiSearcher w/per-index filtering
Hi Peter,
I think this is already taken care of by CachingWrapperFilter - because
its
caching is (like filtering)
Hi Peter,
I think this is already taken care of by CachingWrapperFilter - because its
caching is (like filtering) by IndexReader, and search by a multiSearcher
eventually attempts to filter against each underlying reader, and those
"sub-" filters are being cached.
So it seems to me that if you ju
On Apr 20, 2007, at 3:08 PM, Kirk Roberts wrote:
Grant Ingersoll wrote:
I will try to take a crack at these, but not sure I know exactly
what you are looking for, so maybe others can chime in too.
At any rate, MultiSearcher has been around a lot longer (2001
versus 2004, or at least that is
Grant Ingersoll wrote:
I will try to take a crack at these, but not sure I know exactly what
you are looking for, so maybe others can chime in too.
At any rate, MultiSearcher has been around a lot longer (2001 versus
2004, or at least that is what the changelog seems to indicate) and it
works
You are correct, sir! I failed Lucene History 101 :-) And I failed
my fundamental rule for discussing a search library, which is to do a
search first to see if the answer already exists!
At any rate, here's some history on it: http://www.gossamer-
threads.com/lists/lucene/java-dev/22104
N
On 4/18/07, Grant Ingersoll <[EMAIL PROTECTED]> wrote:
At any rate, MultiSearcher has been around a lot longer (2001 versus
2004, or at least that is what the changelog seems to indicate)
That doesn't sound right... MultiReader is more fundamental as it's needed
to read any multi-segment index.
I will try to take a crack at these, but not sure I know exactly what
you are looking for, so maybe others can chime in too.
At any rate, MultiSearcher has been around a lot longer (2001 versus
2004, or at least that is what the changelog seems to indicate) and
it works over Searchables, in
: Could someone enlighten me a bit about the subject? When do I want to
: use a MultiSearcher rather than a searcher running of a MultiReader?
: There seems to be a bunch of limitations in the MultiSearcher, and it
: is these that made me curious.
as i understand it the limitations of the MultiSe
Hi
MultiSearcher we have used whenwe use more than one folder. As of we used
so far we did not had much issues with multisearcher. The index at times
becomes slow when you incluse more no of folder to search
We have the full index in one folder and the incremental index in another
folder so that
Hi Dan,
java.io.IOException: read past EOF
at org.apache.lucene.store.InputStream.refill(InputStream.java:154)
at org.apache.lucene.store.InputStream.readByte(InputStream.java:43)
at org.apache.lucene.store.InputStream.readBytes(InputStream.java
:57)
at org.apache.luc
Right, we get a different query for each index . You can merge the
results, but, from what I understand, the scores are relative to an
index, so comparing scores may not be meaningful.
>>> [EMAIL PROTECTED] 09/14/05 10:45 AM >>>
Just some thoughts - no answers.
As the analyser for each ind
[EMAIL PROTECTED] wrote:
Just some thoughts - no answers.
As the analyser for each index is different then the query produced by the
query parser will be different.
I had understand it this way, thank you for confirming it.
It may be that you will have to create a query per index then run
Just some thoughts - no answers.
As the analyser for each index is different then the query produced by the
query parser will be different.
It may be that you will have to create a query per index then run the
multiple queries on each index separately. You would then need to somehow
combine
Thank you for your answer Grant.
I already have a similar architecture than yours, allowing me do
retrieve the analyzer used for a specific index.
But how does it solve the problem of doing one search on multiple
indices using multiple analyzer ?
I'm not sure I was enough clear when asking my
I store an Index (not part of Lucene) object w/ the Lucene index that
contains a bunch of metadata about the index, one being the name of the
Analyzer used (other things include the language of the Index, which
field contains a unique document identifier (not the internal Lucene
id), etc. Then at
Olivier Jaquemet wrote:
I have many indices, one for each language, each one has been indexed
using a specific analyzer.
I want to search in all my indices, but I still want/need to use the
same analyzer that has been used for indexing.
MultiSearch only accept one query, and if I use for exampl
Quoting Andrzej Bialecki <[EMAIL PROTECTED]>:
> Regarding Luke - actually, it would not be so difficult to implement
> this (at least for me ;-) ). Save for some minor exceptions, Luke opens
> an IndexReader once, and I could add another version of the Open dialog
> to use open multiple indexes.
>
: On another note, is there any support for before/after phrase queries? I need
to
: construct a query that is able to search for documents where specific phrases
: must appear in a fixed order in a document. For example, "Nobel Prize" must
: occurr before "Roger Penrose" which must occurr before
KW Kor wrote:
Hi folks,
Just wondering, is there a Lucene graphical user interface that supports
searching over multiple indexes? Normally I'ld use Luke, but it does not
support MultiSearcher and it looks difficult to hack Luke.
Hi,
Regarding Luke - actually, it would not be so difficult to impleme
On May 18, 2005, at 2:33 PM, KW Kor wrote:
On another note, is there any support for before/after phrase
queries? I need to
construct a query that is able to search for documents where
specific phrases
must appear in a fixed order in a document. For example, "Nobel
Prize" must
occurr before "
54 matches
Mail list logo
