Re: Fast way to get all Terms in a matching query

2010-07-26 Thread findbestopensource
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

Lucene Index Vs Database Index

2010-07-26 Thread shravan
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

Re: java.io.IOException: background merge hit exception: Caused by: java.io.FileNotFoundException: _1vw.fdt

2010-07-26 Thread David Sitsky
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

Fast way to get all Terms in a matching query

2010-07-26 Thread Philippe
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"

Re: Fastest way to get number of matching documents

2010-07-26 Thread Philippe
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

Re: Fastest way to get number of matching documents

2010-07-26 Thread 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 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

Re: Fastest way to get number of matching documents

2010-07-26 Thread Michael McCandless
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

Fastest way to get number of matching documents

2010-07-26 Thread Philippe
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]

Re: java.io.IOException: background merge hit exception: Caused by: java.io.FileNotFoundException: _1vw.fdt

2010-07-26 Thread Michael McCandless
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

Re: java.io.IOException: background merge hit exception: Caused by: java.io.FileNotFoundException: _1vw.fdt

2010-07-26 Thread David Sitsky
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