[ https://issues.apache.org/jira/browse/SOLR-9185?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16416035#comment-16416035 ]
Steve Rowe commented on SOLR-9185: ---------------------------------- bq. I would like to note that this issue actually included an API change in a minor Solr version without prior deprecation warnings, changing SolrQueryParserBase.init 's signature. I think this should've been avoided as I don't see how it relates to the rest of the issue, or at least be mentioned explicitly if already included, and preferably moved to a major version update. You're right, it was an unrelated cleanup of an unused parameter. As I noted in a comment above: bq. In addition to the grammar changes, I've removed the Version matchVersion param from SolrQueryParserBase.init() - it was being ignored, and the equivalent param was removed from the Lucene classic QueryParser in LUCENE-5859. > Solr's edismax and "Lucene"/standard query parsers should optionally not > split on whitespace before sending terms to analysis > ----------------------------------------------------------------------------------------------------------------------------- > > Key: SOLR-9185 > URL: https://issues.apache.org/jira/browse/SOLR-9185 > Project: Solr > Issue Type: New Feature > Reporter: Steve Rowe > Assignee: Steve Rowe > Priority: Major > Fix For: 6.5, 7.0 > > Attachments: SOLR-9185.patch, SOLR-9185.patch, SOLR-9185.patch, > SOLR-9185.patch > > > Copied from LUCENE-2605: > The queryparser parses input on whitespace, and sends each whitespace > separated term to its own independent token stream. > This breaks the following at query-time, because they can't see across > whitespace boundaries: > n-gram analysis > shingles > synonyms (especially multi-word for whitespace-separated languages) > languages where a 'word' can contain whitespace (e.g. vietnamese) > Its also rather unexpected, as users think their > charfilters/tokenizers/tokenfilters will do the same thing at index and > querytime, but > in many cases they can't. Instead, preferably the queryparser would parse > around only real 'operators'. -- This message was sent by Atlassian JIRA (v7.6.3#76005) --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org