On Tue, Jan 16, 2007 at 11:49:12AM +0100, Martin Bernd Schmeil wrote: > Hi Jens, > [..] > The main issues we have is the well known locking problem and the > scores.
Making sure you only have one process writing to the index, i.e. via an indexer running in backgroundrb, should solve these issues. > The scores leave us with the problem that - while the order seems to be > correct - we don't know where to cut the line to display results and > what a relevant match is. For a dozen attributes I've seen scores from > 0.something to 9.something, with a result close below 9 not even > looling similar while just above 9 seems to be a "99 percent" match. the calculation of scores is quite complex. To get an idea what happens in there you can use Ferret's explain method (in Ferret::Search::Searcher). > If someone would tell me - in case this is possible at all - how to > normalize the scores I'd be very happy. no idea if this is possible - maybe you find some information about this in the context of Lucene (i.e. in Eric Hatcher's fine Lucene book or on the lucene mailing list). > Another thing which I didn't understand yet is what actually happens if > I do a multi token fuzzy search; currently I'm splitting the string up > in multiple tokens and build one query "attribute:token1~ AND > attribute:token2~ AND ...". Maybe not really what I should do to get > correct scores. don't know if there is another way to express this with ferret. cheers, Jens -- webit! Gesellschaft für neue Medien mbH www.webit.de Dipl.-Wirtschaftsingenieur Jens Krämer [EMAIL PROTECTED] Schnorrstraße 76 Tel +49 351 46766 0 D-01069 Dresden Fax +49 351 46766 66 _______________________________________________ Ferret-talk mailing list [email protected] http://rubyforge.org/mailman/listinfo/ferret-talk
