Of course, you can make use of addIndexes and merge existing indices that way.
Otis
--
Sematext -- http://sematext.com/ -- Lucene - Solr - Nutch
- Original Message
> From: Chris Hostetter <[EMAIL PROTECTED]>
> To: "java-user@lucene.apache.org"
> Sent: Saturday, May 10, 2008 12:43:10 P
Did you try the IndexSearcher.doc(int i, FieldSelector fieldSelector) method?
Could be faster because Lucene don't have do "prepare" the whole document.
Patrick
On Sat, May 10, 2008 at 9:35 AM, Stephane Nicoll
<[EMAIL PROTECTED]> wrote:
> From the FAQ:
>
> "Don't iterate over more hits than nee
Hi Steve,
i used the locale as "ar" and it works fine .
again thanks a lot for your help.
Esra
Steven A Rowe wrote:
>
> Hi Esra,
>
> On 05/06/2008 at 7:38 AM, esra wrote:
>> i tried the class and it works fine with the locale parameter "ar".
>
> Cool, I'm glad this addressed your problem!
Sorry I don't get it. Do you have a sample code?
Sent from my iPhone
On 10 May 2008, at 17:43, "John Wang" <[EMAIL PROTECTED]> wrote:
If your indexed field is not used to further filtering out the doc nor
further scoring, you should use some sort of priority queueing
mechanism to
gather the
: Currently, segment file names all start with _0, and increase with each new
: segment created. But seems there is no easy way to change the segment file
: names.
:
: This causes trouble when copying one index to another index's directory, if
: the .cfs files have the same name.
This isn't somet
If your indexed field is not used to further filtering out the doc nor
further scoring, you should use some sort of priority queueing mechanism to
gather the top N documents. You can then call reader.document() on those
docs if necc.
-John
On Sat, May 10, 2008 at 6:35 AM, Stephane Nicoll <[EMAIL
>From the FAQ:
"Don't iterate over more hits than needed.
Iterating over all hits is slow for two reasons. Firstly, the search()
method that returns a Hits object re-executes the search internally
when you need more than 100 hits. Solution: use the search method that
takes a HitCollector instead."
Dear all,
I'm a recent Lucene user and I'm looking for the best way to perform searches
over long titles (ad titles on a website).
For example, if the following documents exist:
- TITLE, "Fender telecaster"
- TITLE, "Land rover defender"
- TITLE, "I sale a wonderful fender st
Just to bring closure on this issue... after numerous iterations with
Marcelo, adding diagnostics to Lucene to isolate the cause of this
exception, it turns out that it's a bug in Oracle 11g's JRE.
Marcelo worked it down to a single document, which when added to a new
index, would hit the except
Daniel,
Think you've cracked it thanks. If I search for "purpl" I get the hits I
expect. Suspect I'm doing something wrong with compass as I presume it
should be converting "purple" to "purpl" before passing the query to
lucene. I've tried explicitly telling it to use snowball at point of query,
On Samstag, 10. Mai 2008, Stephen Cresswell wrote:
> If it was a difference between indexing / querying, why would lucene
> find the word "ribbon" and not "purple" even though they appear in the
> same document and are both exact matches?
Using Snowball, "purple" becomes "purpl" but "ribbon" isn'
If it was a difference between indexing / querying, why would lucene find
the word "ribbon" and not "purple" even though they appear in the same
document and are both exact matches?
AFAIK with grails searchable plugin all you have to do to the correct config
file.
Map compassSettings = ['compass.
On Samstag, 10. Mai 2008, Stephen Cresswell wrote:
> For some reason it seems that either Lucene or Snowball has a problem
> with the color purple. According the snowball experts the problem is
> with lucene. Can anyone shed any light? Thanks,
You are aware that you need to use the same analyzer
13 matches
Mail list logo
