lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Bennett <mbenn...@ideaeng.com>
Subject Re: FuzzyQuery vs SlowFuzsyQuery docs? -- was: Re: [jira] [Commented] (LUCENE-2667) Fix FuzzyQuery's defaults, so its fast.
Date Sun, 28 Oct 2012 19:52:51 GMT
+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. / mbennett@ideaeng.com
Direct: 408-733-0387 / Main: 866-IDEA-ENG / Cell: 408-829-6513


On Thu, Sep 13, 2012 at 7:31 PM, Yonik Seeley <yonik@lucidworks.com> wrote:

> On Thu, Sep 13, 2012 at 6:41 PM, Jack Krupansky <jack@basetechnology.com>
> 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: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
>

Mime
View raw message