If you know the extension during Index time then you could create a
separate field and store all its related content.
E.G: TITLE_EXTN: Lucene Apache Manning ..
Search on this field will give you faster results.
Regards
Aditya
www.findbestopensource.com
On Tue, Jul 27, 2010 at 1:04 AM, Philippe
Hi,
Can any one clarify me difference between lucene index and database index?
I am just trying to understand how lucene stores index, like databases store
index as b-tree's.
Thank in advance,
Shravan
---
--
View this message in context:
http://lucene.472066.n3.nabble.com/Lucene-I
During processing.. there might be a number of reasons why we need to
shutdown the indexing process, but perhaps what is unusual is we call
the win32 API TerminateProcess() call rather than System.exit(), for
slightly obscure reasons. When calling exit(), this still calls a
large body of code (for
Hi,
I'm looking for an efficient way to query lucene multiple times. All
queries are an extension of the very first query with only one term.
(E.g. "Title:Lucene"
-> "Title:Lucene Title:Apache"
-> "Title:Lucene Title:Manning"
My current solution uses "CachingWrapperFilter"
Hi Paul,
thanks for the code. It is much faster than the implementation before.
Cheers,
Philippe
Am 26.07.2010 16:25, schrieb Paul Libbrecht:
Le 26-juil.-10 à 16:01, Michael McCandless a écrit :
You can make a custom Collector? Ie, it'd just increment a counter
for each hit.
As long a
Le 26-juil.-10 à 16:01, Michael McCandless a écrit :
You can make a custom Collector? Ie, it'd just increment a counter
for each hit.
As long as it does not call the Scorer.score() method then no
scoring is done.
I've done that.
Code below.
It feels a bit stupid to have to do that thoug
You can make a custom Collector? Ie, it'd just increment a counter
for each hit.
As long as it does not call the Scorer.score() method then no scoring is done.
Mike
On Mon, Jul 26, 2010 at 9:18 AM, Philippe wrote:
> Hi,
>
> for some queries I'm only interested in the number of matching documen
Hi,
for some queries I'm only interested in the number of matching
documents. Is there a better/faster way to perform such a query, instead
of retrieving all TopDocs and counting the number of totalHits [1]?
And is it possible/worthwhile to "deactivate" ranking?
Cheers,
Philippe
[1]
It's great that CheckIndex resolved it, but I'd like to get to the
root cause if possible.
Can you describe how the previous indexing process abnormally
terminated? Did the JRE crash/get killed? Did the OS/machine crash /
lose power?
Abnormal termination of any kind, background merges running o
Running CheckIndex -fix fixed both indexes which is a relief. In both
cases, it said 1 broken segment containing 1 document detected.
So any ideas on what might have caused this in the first place?
On 26 July 2010 16:58, David Sitsky wrote:
> As another data point, this happened on another inde
10 matches
Mail list logo
