[
https://issues.apache.org/jira/browse/LUCENE-2262?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12833493#action_12833493
]
Yonik Seeley commented on LUCENE-2262:
--------------------------------------
bq. yonik, that's not what this issue is about. have you looked at the patch?
Nope, I was going by the comments. Looks like I misinterpreted them. Sorry.
As an aside: In solr-land I encourage adding API examples, etc, to lower the
bar for giving feedback (i.e. they don't have to read the patch to give an
opinion on what the syntax of a new request should look like). That's not a
criticism of your description (which was fine) but rather the implication that
I should have read the patch (and I may have misread that too).
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.
Agree.
> 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 docs say this:
> {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 flex branch, this is no longer true. foo?, ?foo, f?oo, these 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: [email protected]
For additional commands, e-mail: [email protected]
