I was able to get this whole thing to work using the delegation pattern. In
my custom collector object, internally delegate to the TopFieldCollector
after doing my custom processing.
Thanks.
--
View this message in context:
http://lucene.472066.n3.nabble.com/Problem-using-TopFieldCollector-tp
OK I updated that wiki page w/ details about what's been committed to 4.0-dev...
Mike
On Tue, Jun 15, 2010 at 2:38 AM, Simon Willnauer
wrote:
> On Mon, Jun 14, 2010 at 10:48 PM, Michael McCandless
> wrote:
>> Alas there is no wiki page yet; I will get one started!
>
> Actually there is one, htt
CheckIndex is not able to recover from this corruption (missing
segments_N file); this would be a nice addition...
But it sounds like you've worked out a way to write your own segmetns_N?
Use oal.store.ChecksumIndexOutput (wraps any other IndexOutput) to
properly write the checksum.
BTW how did
Also remember that a String object in Java has a high overhead -- the
object header (maybe 8 bytes), 3 int fields, a pointer (4 or 8 bytes)
to the (separate) char[], and then another object header for that
char[], and 2 bytes per character in the string.
Lucene trunk (4.0-dev) has cutover to share
On Thu, 2010-06-10 at 04:03 +0200, fujian wrote:
> Another thing is about unique. I thought it was unique "field value". If it
> means unique term, for English even loading all around 300,000 terms it
> won't take much memory, right? (Suppose the average length of term is 10,
> the total memory usa
Dear Ian,
The segment you have suggested, working nicely. Thanx a lot for your kind
help.
Manjula.
On Fri, Jun 11, 2010 at 4:00 PM, Ian Lea wrote:
> Something like this
>
> File f = new File(path);
> String fn = f.getName();
> return fn.substring(0, fn.lastIndexOf("."));
>
>
> --
> Ian.
>
>
>
