# Why query\_string doesn't honor the usual precedence rules? **URL:** \ **Category:** Elasticsearch\ **Created:** [September 16, 2020, 7:13am UTC](https://discuss.elastic.co/t/why-query-string-doesnt-honor-the-usual-precedence-rules/248779 "2020-09-16T07:13:50Z")\ **Posts on this page:** 1\ **Showing post:** 3
**Author:** ![Mark\_Harwood](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/mark_harwood/32/10538_2.png) [@Mark\_Harwood](https://discuss.elastic.co/u/Mark_Harwood)\ **Post date:** [September 18, 2020, 8:57am UTC](https://discuss.elastic.co/t/why-query-string-doesnt-honor-the-usual-precedence-rules/248779/3 "2020-09-18T08:57:46Z")
I had a look into this using the [validate query](https://www.elastic.co/guide/en/elasticsearch/reference/current/search-validate.html) API. Here's the command to debug `aa OR bb AND cc`: ``` GET githubcommits/_validate/query?q=aa+OR+bb+AND+cc&rewrite=true&df=myfield ``` The result is: ``` "explanation" : "myfield:aa +myfield:bb +myfield:cc" ``` Lucene's Boolean query has the idea of mandatory `must` clauses and `should` clauses which are just nice-to-haves. In the above query `aa` is relegated to a wholly optional `should` clause that gives extra scoring points to documents that contain both of the mandatory `must` clauses bb and cc. If you want to have pure OR clauses in Lucene you need to use a Boolean query with `should` clauses but no `must` clauses. Something like this: ``` bool should aa bool must bb cc ``` Note the use of a nested bool query above to get the required logic. The introduction of brackets in query\_string syntax forces the creation of these sub boolean clauses and makes the logic behave in a more predictable way. Weird, but I'd hesitate to call it a bug - more a quirk of Lucene. For readability's sake alone I would advocate using brackets to make the logic clear. --- _[View the full topic](https://discuss.elastic.co/t/why-query-string-doesnt-honor-the-usual-precedence-rules/248779)._