2011-05-14
haichengyl
发件人： hao yan
发送时间： 2011-05-14 04:56:27
收件人： java-user
抄送： Xiaoyang Gu; hao yan
主题： A bug in multisearcher?
hi, guys
Xiaoyang and I today just found a bug of lucene.
This is actually a Multi-searcher bug. In particular,
If we search with Not on NumericRange a
Hi,
This is a well-known bug, which is unfixable (query rewrite across different
searchers is wrong). In general you should use a MultiReader on your
IndexReaders and use a simple IndexSearcher on top of that MultiReader.
MultiSearcher and ParallelMultiSearcher were deprecated in 3.1 because of
th
hi, guys
Xiaoyang and I today just found a bug of lucene.
This is actually a Multi-searcher bug. In particular,
If we search with Not on NumericRange and we use MultiSearcher, we
will wrong search results (However, if we use IndexSearcher, the
result is correct). Basically the NotOfNumericRange
Hi Ivan and Robert,
>> sounds like you should talk to Tom Burton-West!
Ok, I'll bite.
A few questions:
Are you planning to have separate fields for each language or the same fields
with contents in different languages?
If #2 are you planning to have a field to indicate the language so you can d
Chris, and others
Thanks for your reply. In effect what you are saying is that
SpanNearQuery works as expected, and I should set inOrder=true to obtain
the behaviour I require, even though I don't care about the order?
Thanks
Greg
-Original Message-
From: Chris Hostetter [mailto:hossma
Hi,
In my quest to fight a similar problem, I ended up writing a wrapper
finalizer (sic!) that simply closes the underlying reader/searcher. It
might be against all advices (e.g. "Effective Java 2ed" Item 7) but I
simply couldn't find any better solution to this problem.
I wish I wouldn't need do
Apologies for a long silence - have been fighting a nasty bug of a non-computer
variety.
We are using 3.0.3. I was trying to upgrade to 3.1 and clear all deprecation
warnings. What I described was an attempt to switch from MultiSearcher to
MultiReader. We had a simple delegating IndexSearcher w
On Fri, 2011-05-13 at 12:11 +0200, Samarendra Pratap wrote:
> Comparison between - single index Vs 21 indexes
> Total Size - 18 GB
> Queries run - 500
> % improvement - roughly 18%
I was expecting a lot more. Could you test whether this is an IO-issue
by selecting a slow query and performing the e
Hi Tom,
Thanks for pointing me to something important (phrase queries) which I
wasn't thinking of.
We are using synonyms which gets expanded at run time. I'll have to give it
a thought.
We are not using synonyms at indexing time due to lack of flexibility of
changing the list. We are not using
