translates to:
Doc ID Freq.
7 1
18 3
Instead of documents 7 and 11 as described in the paragraph above the
example.
Shouldn't the example be '15, 8, 3'?
Kind regards,
Johan Stuyts
Hippo
-
> I just searched for 'faceted' on the e-mails I've seen since
> I subscribed to
> the list, and there are certainly discussions out there...
I did already, but...
> This thread might be particularly useful, started 15-May-2006
> *Aggregating category hits
it seems I missed this one. Thanks.
> > So my questions are: is there a way to prevent the IndexWriter from
> > merging, forcing it to create a new segment for each indexing batch?
>
> Already done in the Lucene trunk:
> http://issues.apache.org/jira/browse/LUCENE-672
>
> Background:
> http://www.gossamer-threads.com/lists/lucene/j
> Why go through all this effort when it's easy to make your
> own unique ID?
> Add a new field to each document "myuniqueid" and fill it in
> yourself. It'll
> never change then.
I am sorry I did not mention in my post that I am aware of this solution
but that it cannot be used for my purposes.
atch? And
if so, will it still be possible to merge the disk segments when I want
to?
Kind regards,
Johan Stuyts
Hippo
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
> I don't think it really matters wether you do deletes on the same
> IndexReader -- what matters is if there has been any deletes
> done to the
> index prior to opening the reader since it was last
> optimized. The reason
> being that deleting a document just causes a record of the
> deletion
lt; df) {
doc += freqStream.readVInt() >>> 1;
count++;
destination.set(doc);
}
// Leave a consistent state
this.doc = doc;
freq = 1;
this.count = df;
}
By using the method above I gained a speed improvement of over 20
