[
https://issues.apache.org/jira/browse/SOLR-4333?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James Dyer updated SOLR-4333:
-----------------------------
Attachment: SOLR-4333.patch
Here's a patch with a fix.
The "splitIntoClauses" logic escapes colons in a special after-the-fact bit of
code, but this does not take into account that some colons might already have
been escaped. This results in two backslashes followed by a colon which in
turn produces a query parser exception. This causes edismax to go into
full-escape mode resulting in the surprise described already here.
The patch changes this to not escape a colon again if it has already been
escaped.
> edismax query with escaped colon ignores AND and OR
> ---------------------------------------------------
>
> Key: SOLR-4333
> URL: https://issues.apache.org/jira/browse/SOLR-4333
> Project: Solr
> Issue Type: Bug
> Components: query parsers
> Affects Versions: 4.0
> Environment: tomcat 7.34
> java 7u11
> windows 2008R2
> Reporter: Robert J. van der Boon
> Attachments: SOLR-4333.patch, SOLR-4333.patch, SOLR-4333.patch
>
>
> When I use the edismax query handler with qf=samenvatting and have a query of
> the form
> {noformat}
> a\:b AND cde
> {noformat}
> then the parsedquery ends up as:
> {noformat}
> (+(DisjunctionMaxQuery((samenvatting:"a b"))
> DisjunctionMaxQuery((samenvatting:and))
> DisjunctionMaxQuery((samenvatting:cde))))/no_coord
> {noformat}
> note that the AND operator is ignored, and a search for the word AND is
> performed.
> As far as I've seen it doesn't matter if the part before the \: is a real
> field or not.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
