Hi,
1) I did not read IndexDocValues code, but it looks like it may not fully meet
your needs, other experts
may comment.
2) No, that's not what I meant, I meant during index time, we can create a
field to contain as much as
useful information as possible for later scoring, then in Cust
Do we have a body for Lucene Users from Mumbai, India ?
From: KARTHIK SHIVAKUMAR
To: java-user@lucene.apache.org
Date: 11-12-2011 19:03
Subject:Re: Lucene bangalore chapter
Hi
I definitely think there is NONE.. ;)
with regards
karthik
On Tue, Dec 6, 2011 at 11:41 A
hey,
so what I wonder in general is if the benchmarks are comparable. What
I mean is that the benchmark code has changed since 2.4 a lot so there
might be additional fields and / or different settings on what to
index and how.
could you check with luke if the index has the same fields and if the
s
Hi
According to
http://www.gossamer-threads.com/lists/lucene/java-dev/37421
one cannot overwrite the default write lock timeout of 1000ms once a
write.lock already exists (for example inside a multi-threaded
web-application), because in order to use the method
setWriteLockTimeout(long) one
I know how to get relevant highlighted fragments together with some surrounding
text using Lucene highlighter, namely, using
Highlighter highlighter = new Highlighter(scorer);
String[] fragments = highlighter.getBestFragments(stream,
fieldContents, fragmentNumber);
But c
Simon,
I checked the indexes with Luke and you were right about the benchmarks may
not be comparable since they had different number of fields and index
functionalities. You can find the summaries of the index statistics for 2.4.1,
2.9.4, and 3.5.0 below.
I also ran the benchmarks for the st
Hi,
I modified the DocMaker in 3.5 to make it index the same 4 fields as 2.4.1
does. Now I got very similar stats in the index by checking Luke. The index
performance was slightly better than that by indexing 7 fields but still not
comparable with the 2.4.1 performance:
[java] > R
