+1 !!! Also a BIG +1 for leaving the old logic around.
I've been discussing this with a client, on behalf of their clients. They're fine with the slower speed, and they need the option of lower percentage matches, which they combine with other business logic, to insure acceptable matches. ***My fear is that the deprecated stuff then later goes away completely in subsequent releases. This would actually prevent them from upgrading further (without patches, etc)*** Is it now the case that if the parser sees a floating point number 0.0 to 1.0 it uses the older/slower code, whereas just ~ or ~(integer) uses the new code? They also prefer the percent match syntax, though I realize that's a different issue. -- Mark Bennett / New Idea Engineering, Inc. / [email protected] Direct: 408-733-0387 / Main: 866-IDEA-ENG / Cell: 408-829-6513 On Thu, Sep 13, 2012 at 7:31 PM, Yonik Seeley <[email protected]> wrote: > On Thu, Sep 13, 2012 at 6:41 PM, Jack Krupansky <[email protected]> > wrote: > > I would argue that > > SlowFuzzyQuery should be un-deprecated and moved from sandbox back into > > Lucene proper since it does have value in SOME cases. Actually, I would > > argue that it should be recombined with "fast" FuzzyQuery (joined at the > hip > > as it were) and simply document that if you use a max edit distance > 2 > then > > it will be "slow". > > +1 > Sounds reasonable to me. > > -Yonik > http://lucidworks.com > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
