One more observation.
The length of the snippet returned is not equal to the fragment length
specified.
Does anyone know the reason why?
On Wed, Sep 22, 2010 at 3:05 PM, Devshree Sane wrote:
> Thanks for your reply Koji.
>
> On Wed, Sep 22, 2010 at 4:51 AM, Koji Sekiguchi wrote:
>
>> (10/09/22
I have a set of documents that all have a "timestamp" field which is stored as
a long integer number. The field is indexed in my Lucene index as a number
using NumericField with a precision step of 8:
Field field = new NumericField("timestamp", 8);
field.setLongValue( timestampValue);
Hi,
Can you provide some self-containing testcase that shows your problem? In
most cases those problems are caused by not committing changes to
IndexWriter before opening the IndexReader.
Additionally, if you only want to look for exactly one timestamp (like a
TermQuery), use a NumericRangeQuery
Thank you for your timely response.
It's going to take me longer to create an isolated test case you can test this
with. I will see what I can do.
In the meantime, I have some follow up information in response to your other
suggestions.
1) I don't think my problem is that the IndexWriter
Hi,
> Thank you for your timely response.
:-)
> It's going to take me longer to create an isolated test case you can test
this
> with. I will see what I can do.
That would be fine. Often with a simple test those errors disappear, because
they are problem in the logic somewhere else :) But you
I'm certain the timestamp field is being indexed. It is created as follows:
Document doc = new Document();
NumericField timeField = new NumericField("timestamp", 8); // Defaults to
indexing = true.
timeField.setLongValue( timeX);
doc.add( timeField);
...
indexWriter.a
Hi,
A user got this very strange exception, and I managed to get the index
that it happens on. Basically, iterating over the TermDocs causes an AAOIB
exception. I easily reproduced it using the FieldCache which does exactly
that (the field in question is indexed as numeric). Here is the except
Hi,
We are using lucene 2.3.2, now we need to index each document as
fast as possible, so user can almost immediately search it.
So I am considering stop IndexWriter optimization during real time,
then in relatively off-time like late night we may call IndexWriter optimize
method explicitly onc
Shay,
would you mind open a jira issue for that?
simon
On Fri, Sep 24, 2010 at 2:53 AM, Shay Banon wrote:
> Hi,
>
> A user got this very strange exception, and I managed to get the index
> that it happens on. Basically, iterating over the TermDocs causes an AAOIB
> exception. I easily reprod
Hi,
I read document/code and did some experiments, one possibility
is to raise mergeFactor to high value, say close to 2Billion,
then a lot of small files are created and after >500 docs are
created separately, search speed dropped sharply.
I noticed with our current data, if I add one doc then c
10 matches
Mail list logo
