# Default\_operator 'AND' with query\_string does not work properly **URL:** \ **Category:** Elasticsearch\ **Created:** [October 15, 2019, 2:11pm UTC](https://discuss.elastic.co/t/default-operator-and-with-query-string-does-not-work-properly/203667 "2019-10-15T14:11:49Z")\ **Posts on this page:** 6\ **Page:** 1
**Author:** ![Flinou](https://avatars.discourse-cdn.com/v4/letter/f/ebca7d/32.png) [@Flinou](https://discuss.elastic.co/u/Flinou)\ **Post date:** [October 15, 2019, 2:11pm UTC](https://discuss.elastic.co/t/default-operator-and-with-query-string-does-not-work-properly/203667/1 "2019-10-15T14:11:49Z")
I have some issues trying to make default\_operator AND work with query\_string on multiple fields. (Elastic Search v 7.2) Here is my query and the document indexed : ``` POST testeur/_doc/document { "content": "attention dans la revision", "main_title" : "fichier dans la voiture" } GET testeur/_search { "query": { "query_string": { "query": "attention voiture", "default_operator": "AND", "fields": ["content","main_title"] } } } ``` I have no results when launching the request above. The document is retrieved with the request below (specifying the operator AND directly in the query field) though : ``` GET testeur/_search { "query": { "query_string": { "query": "attention AND voiture", "fields": ["content","main_title"] } } } ``` I guess I am doing something wrong with the default\_operator field. Unfortunalety, I have no clue what's wrong despite reading the query\_string documentation. Especially when reading this part about default\_operator in query\_string documentation : > AND > For example, a query string of capital of Hungary is interpreted as capital > AND of AND Hungary. That's exactly what I intend to do. Could you provide any help please ? ---
**Author:** ![dadoonet](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/dadoonet/32/137187_2.png) [@dadoonet](https://discuss.elastic.co/u/dadoonet)\ **Post date:** [October 15, 2019, 4:53pm UTC](https://discuss.elastic.co/t/default-operator-and-with-query-string-does-not-work-properly/203667/2 "2019-10-15T16:53:18Z")
Interesting. @jpountz WDYT? The behavior does not look consistent indeed. I guess that behind the scene we do something like: `content:(attention AND voiture) main_title:(attention AND voiture)`, right? ---
**Author:** ![Flinou](https://avatars.discourse-cdn.com/v4/letter/f/ebca7d/32.png) [@Flinou](https://discuss.elastic.co/u/Flinou)\ **Post date:** [October 18, 2019, 1:32pm UTC](https://discuss.elastic.co/t/default-operator-and-with-query-string-does-not-work-properly/203667/3 "2019-10-18T13:32:00Z")
Thank you for your reply. As I am stil stuck with that problem, I allow myself to post this message to get more assistance. ---
**Author:** ![Flinou](https://avatars.discourse-cdn.com/v4/letter/f/ebca7d/32.png) [@Flinou](https://discuss.elastic.co/u/Flinou)\ **Post date:** [October 31, 2019, 10:09am UTC](https://discuss.elastic.co/t/default-operator-and-with-query-string-does-not-work-properly/203667/4 "2019-10-31T10:09:23Z")
I've got some information on the internet. Here is the link if someone encounters the same issue : [Link](https://stackoverflow.com/questions/57904019/elasticsearch-and-in-query-string-vs-default-operator-and) The way Elastic handles default\_operator AND in multiple fields query\_string request does not seem correct with regard to the doc. ---
**Author:** ![javanna](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/javanna/32/4698_2.png) [@javanna](https://discuss.elastic.co/u/javanna)\ **Post date:** [November 8, 2019, 1:55pm UTC](https://discuss.elastic.co/t/default-operator-and-with-query-string-does-not-work-properly/203667/5 "2019-11-08T13:55:55Z")
Hello, sorry about the wait. I have given this a try and used the validate query API with explain option activated: GET [http://localhost:9200/testeur/\_validate/query?q=attention%20voiture&default\_operator=AND&explain=true](http://localhost:9200/testeur/_validate/query?q=attention%20voiture&default_operator=AND&explain=true) ```auto { "_shards": { "total": 1, "successful": 1, "failed": 0 }, "valid": true, "explanations": [ { "index": "testeur", "valid": true, "explanation": "(content.keyword:attention voiture | main_title.keyword:attention voiture | (+content:attention +content:voiture) | (+main_title:attention +main_title:voiture))" } ] } ``` GET [http://localhost:9200/testeur/\_validate/query?q=attention%20AND%20voiture&explain=true](http://localhost:9200/testeur/_validate/query?q=attention%20AND%20voiture&explain=true) ```auto { "_shards": { "total": 1, "successful": 1, "failed": 0 }, "valid": true, "explanations": [ { "index": "testeur", "valid": true, "explanation": "+(content.keyword:attention | main_title.keyword:attention | content:attention | main_title:attention) +(content.keyword:voiture | main_title.keyword:voiture | content:voiture | main_title:voiture)" } ] } ``` This explains the difference in the outcome from the two queries. This is very subtle, and I don't even know which one of the two is the right behaviour. I guess it's debatable and depends what users expect. Note that AND or OR operator is generally not enough to describe how you want the operator to be applied when searching for multiple terms against multiple fields, especially when using AND. Do you mean that all terms need to appear on all fields? Or that at least one of the terms has to appear in all the fields? Or that all the terms need to appear in at least one of the fields? This is just more complicated than boolean logic. Unless you need all the power of the query\_string query, I would recommend to look at the match query which offers options to fine-tune this behaviour. Cheers Luca ---
**Author:** ![system](https://us1.discourse-cdn.com/elastic/original/3X/1/a/1ac57faf039f6b580b3f104ef42a2a89e41014de.png) [@system](https://discuss.elastic.co/u/system)\ **Post date:** [December 6, 2019, 2:03pm UTC](https://discuss.elastic.co/t/default-operator-and-with-query-string-does-not-work-properly/203667/6 "2019-12-06T14:03:26Z")
This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.