On 2/27/07, Jeffrey Gelens <[EMAIL PROTECTED]> wrote: > David Balmain wrote: > > Actually 18446744072766697140 is too big for even a 64bit long (or a > > long long on 32bit systems) so I'd love to know where that number is > > coming from. It is obviously a bug somewhere else. Unfortunately it > > would be impractical for you to send me the index. If it is possible > > to give me access to your server I should be able to sort this out > > though. Otherwise, I'll look into it, but I can't promise anything. > > > > Dave > > I can't give access to the server as its a company server, sorry. > Is there a possibility that the index somehow got corrupted? At the > moment I am recreating the index, which takes several days. I'll report > on the findings when it's done.
It could be a corrupt index but I doubt it. I think it is more likely a bug somewhere else. I have built indexes of this size before without problem though. Perhaps if you could give me an idea of what type of data you are putting in the index I could try and rebuild a similar index here to diagnose the problem. ie. how many documents, how many fields, what are the field settings (eg stored, untokenized, term_vectors etc), how large are the fields on average and what sort of data (eg numbers dates english language, code etc) and also what analyzer are you using. This should give me enough information to build a very similar index here and hopefully reproduce the problem. Cheers, Dave PS: send it to me privately if you prefer -- Dave Balmain http://www.davebalmain.com/ _______________________________________________ Ferret-talk mailing list [email protected] http://rubyforge.org/mailman/listinfo/ferret-talk
