i think we can make some reasonable defaults (based on Version) for fuzzy so that its fast.
i'm trying to figure out a way to use TREC's confusion data ( http://trec.nist.gov/data/t5_confusion.html, OCR-damaged test collection), to help determine some defaults so Hoss won't be after me... yes i know OCR isn't the only use case but its better than pure subjective :) On Sat, Feb 13, 2010 at 10:51 PM, Mark Miller <markrmil...@gmail.com> wrote: > Nah, let's just make fuzzy not work in the qp by default :) And make that > back compat while your at it - while not abusing Version so that it's used > for something subjective :) wouldn't want to rile up Hoss. > > I'm like 3/4 serious. > > - Mark > > http://www.lucidimagination.com (mobile) > > > On Feb 13, 2010, at 10:22 PM, "Robert Muir (JIRA)" <j...@apache.org> > wrote: > > >> [ >> https://issues.apache.org/jira/browse/LUCENE-2262?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12833496#action_12833496 >> ] >> >> Robert Muir commented on LUCENE-2262: >> ------------------------------------- >> >> bq. in my opinion disallowing these queries with leading wildcards, be it >> * or ? or whatever, is rather silly, since we allow even slower fuzzyqueries >> by default. >> >> bq. Agree. >> >> What do you think, should we skip this step then and simply deprecate the >> entire setAllowLeadingWildcard concept all together, setting it to true for >> Version >= 3.1? >> >> >> QueryParser should now allow leading '?' wildcards >>> -------------------------------------------------- >>> >>> Key: LUCENE-2262 >>> URL: https://issues.apache.org/jira/browse/LUCENE-2262 >>> Project: Lucene - Java >>> Issue Type: Improvement >>> Components: QueryParser >>> Affects Versions: Flex Branch >>> Reporter: Robert Muir >>> Assignee: Robert Muir >>> Priority: Minor >>> Fix For: Flex Branch >>> >>> Attachments: LUCENE-2262.patch, LUCENE-2262_backwards.patch >>> >>> >>> QueryParser currently throws an exception if a wildcard term begins with >>> the '?' operator. >>> The current documentation describes why this is: >>> {noformat} >>> When set, * or ? are allowed as the first character of a PrefixQuery and >>> WildcardQuery. >>> Note that this can produce very slow queries on big indexes. >>> {noformat} >>> In the flexible indexing branch, wildcard queries with leading '?' >>> operator are no longer slow on big indexes (they do not enumerate terms in >>> linear fashion). >>> Thus, it no longer makes sense to throw a ParseException for a leading >>> '?' >>> So, users should be able to perform a query of "?foo" and no longer get a >>> ParseException from the QueryParser. >>> For the flexible indexing branch, wildcard queries of 'foo?', '?foo', >>> 'f?oo', etc are all the same from a performance perspective. >>> >> >> -- >> This message is automatically generated by JIRA. >> - >> You can reply to this email to add a comment to the issue online. >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org >> For additional commands, e-mail: java-dev-h...@lucene.apache.org >> >> > --------------------------------------------------------------------- > To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: java-dev-h...@lucene.apache.org > > -- Robert Muir rcm...@gmail.com
