[
https://issues.apache.org/jira/browse/SOLR-4258?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13559096#comment-13559096
]
Chris Bleakley commented on SOLR-4258:
--------------------------------------
This behavior also happens with malformed queries. For example, even if all
fields in the QF parameter exist we can still replicate the behavior with a
query with unbalanced parenthesis:
(bar AND grill
gets parsed as
+((title:bar) (title:and) (title:grill))
To replicate use the solr 4.0 example:
http://localhost:8983/solr/select?q=(bar%20AND%20grill&defType=edismax&qf=title&debugQuery=true&lowercaseOperators=false
I've updated the patch with a test case for this as well.
> Edismax query behavior change between 3.5 and 3.6-4.x when undefined field in
> QF param or query malformed
> ---------------------------------------------------------------------------------------------------------
>
> Key: SOLR-4258
> URL: https://issues.apache.org/jira/browse/SOLR-4258
> Project: Solr
> Issue Type: Bug
> Components: search
> Affects Versions: 3.6, 4.0
> Reporter: Chris Bleakley
> Priority: Minor
> Attachments: SOLR-4258.patch, SOLR-4258.patch, SOLR-4258.patch
>
>
> If the following query conditons are met:
> (1) include an operator in your query string ( "AND", "OR", "NOT" )
> (2) include a field in your QF parameter that's not defined your schema
> the query behavior for the edismax handler has changed from 3.5 to 3.6 (and
> continues into 4.x). The behavior can be recreated using following parameters
> on the stock example index:
> q=bar AND grill
> deftype=edismax
> qf=title INVALID
> debugQuery=true
> lowercaseOperators=false
> http://localhost:8983/solr/select?q=bar%20AND%20grill&defType=edismax&qf=title%20INVALID&debugQuery=true&lowercaseOperators=false
> Testing between 3.5 and 3.6 show the following differences between the parsed
> query:
> in 3.5 : +(+(title:bar) +(title:grill))
> in 3.6.0 : +(((title:bar) (title:and) (title:grill))~3)
> In 3.6 the operator has been lowercased and included in the query, even
> though lowercaseOperators is "false"
> I couldn't find any docs that explain how a query should behave with an
> invalid QF param or that the behavior had changed. I took a stab at a patch
> to make 4.x behave as < 3.6, but again, I'm not exactly sure what the
> behavior should be. The patch removes operators from the query string if
> "lowercaseOperators" is false and the query parsing falls past the initial
> parsing attempt. Thanks!
--
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]
