# Query string query mini-language vs. grammar implementation? **URL:** \ **Category:** Elasticsearch\ **Created:** [July 9, 2014, 12:35am UTC](https://discuss.elastic.co/t/query-string-query-mini-language-vs-grammar-implementation/18539 "2014-07-09T00:35:14Z")\ **Posts on this page:** 4\ **Page:** 1
**Author:** ![x0ne\_2](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/x0ne_2/32/1405_2.png) [@x0ne\_2](https://discuss.elastic.co/u/x0ne_2)\ **Post date:** [July 9, 2014, 12:35am UTC](https://discuss.elastic.co/t/query-string-query-mini-language-vs-grammar-implementation/18539/1 "2014-07-09T00:35:14Z")
Ever since I discovered the mini-language provided through the query string query ([http://www.elasticsearch.org/guide/en/elasticsearch/reference/current/query-dsl-query-string-query.html](http://www.elasticsearch.org/guide/en/elasticsearch/reference/current/query-dsl-query-string-query.html)), I have had a hard time going back to the difficult process of mapping what someone wants to a proper elasticsearch query. As such, I have essentially provided users with the ability to create their own query strings and then execute them directly against the cluster (10s of millions of documents). This approach works great until a several complex queries are ran in a row which then appears to send the cluster into an OOM panic. Is there a way to put some sanity checks inside of the query string query to avoid insane results coming back? Can I limit the number of results loaded onto the heap or put into the cache? Have others just rolled their own grammar parsing instead of using the mini-language directly? -- You received this message because you are subscribed to the Google Groups "elasticsearch" group. To unsubscribe from this group and stop receiving emails from it, send an email to [elasticsearch+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com). To view this discussion on the web visit [https://groups.google.com/d/msgid/elasticsearch/c7d5626c-b485-47d0-bcd8-5472bb38b5d3%40googlegroups.com](https://groups.google.com/d/msgid/elasticsearch/c7d5626c-b485-47d0-bcd8-5472bb38b5d3%40googlegroups.com). For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout). ---
**Author:** ![Robert\_Muir\_2](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/robert_muir_2/32/931_2.png) [@Robert\_Muir\_2](https://discuss.elastic.co/u/Robert_Muir_2)\ **Post date:** [July 10, 2014, 12:51pm UTC](https://discuss.elastic.co/t/query-string-query-mini-language-vs-grammar-implementation/18539/2 "2014-07-10T12:51:44Z")
On Tue, Jul 8, 2014 at 8:35 PM, x0ne [brandon.s.dixon@gmail.com](mailto:brandon.s.dixon@gmail.com) wrote: > Ever since I discovered the mini-language provided through the query string > query > ([Elasticsearch Platform — Find real-time answers at scale | Elastic](http://www.elasticsearch.org/guide/en/elasticsearch/reference/current/query-dsl-query-string-query.html)), > I have had a hard time going back to the difficult process of mapping what > someone wants to a proper elasticsearch query. As such, I have essentially > provided users with the ability to create their own query strings and then > execute them directly against the cluster (10s of millions of documents). > > This approach works great until a several complex queries are ran in a row > which then appears to send the cluster into an OOM panic. Is there a way to > put some sanity checks inside of the query string query to avoid insane > results coming back? Can I limit the number of results loaded onto the heap > or put into the cache? Have others just rolled their own grammar parsing > instead of using the mini-language directly? Have you looked at simple query string? > **[Elasticsearch Platform — Find real-time answers at scale](https://www.elastic.co)** > > Power insights and outcomes with the Elasticsearch Platform and AI. See into your data and find answers that matter with enterprise solutions designed to help you build, observe, and protect. Try Elasticsearch free today. This one is more limited, but it has a flags parameter that lets you turn every feature or operator on/off. So you could disable wildcard, phrase, fuzzy, etc. -- You received this message because you are subscribed to the Google Groups "elasticsearch" group. To unsubscribe from this group and stop receiving emails from it, send an email to [elasticsearch+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com). To view this discussion on the web visit [https://groups.google.com/d/msgid/elasticsearch/CAMUKNZVu-f9NiOxByFCzm4zaWVZ0y6%2BypaKqripvPHBDdLLiLQ%40mail.gmail.com](https://groups.google.com/d/msgid/elasticsearch/CAMUKNZVu-f9NiOxByFCzm4zaWVZ0y6%2BypaKqripvPHBDdLLiLQ%40mail.gmail.com). For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout). ---
**Author:** ![Maciej\_Dziardziel](https://avatars.discourse-cdn.com/v4/letter/m/d9b06d/32.png) [@Maciej\_Dziardziel](https://discuss.elastic.co/u/Maciej_Dziardziel)\ **Post date:** [July 10, 2014, 3:25pm UTC](https://discuss.elastic.co/t/query-string-query-mini-language-vs-grammar-implementation/18539/3 "2014-07-10T15:25:27Z")
You can define timeout (adding ie. timeout=400 in url) to limit time ES will spend waiting for results, at the cost of possibility of returning incomplete results. Any "sanity checks" are tricky, as you'd need to define what is allowed, how it will perform against your index, and then parse query to enforce it (and then keep up with lucene on upgrades). If your users don't require complex queries, don't provide them. Since I'm mostly dealing with internet users, I usually write my own parsers. On Wednesday, July 9, 2014 1:35:14 AM UTC+1, x0ne wrote: > Ever since I discovered the mini-language provided through the query > string query ( > [Elasticsearch Platform — Find real-time answers at scale | Elastic](http://www.elasticsearch.org/guide/en/elasticsearch/reference/current/query-dsl-query-string-query.html)), > I have had a hard time going back to the difficult process of mapping what > someone wants to a proper elasticsearch query. As such, I have essentially > provided users with the ability to create their own query strings and then > execute them directly against the cluster (10s of millions of documents). > > This approach works great until a several complex queries are ran in a row > which then appears to send the cluster into an OOM panic. Is there a way to > put some sanity checks inside of the query string query to avoid insane > results coming back? Can I limit the number of results loaded onto the heap > or put into the cache? Have others just rolled their own grammar parsing > instead of using the mini-language directly? -- You received this message because you are subscribed to the Google Groups "elasticsearch" group. To unsubscribe from this group and stop receiving emails from it, send an email to [elasticsearch+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com). To view this discussion on the web visit [https://groups.google.com/d/msgid/elasticsearch/efcc9a1a-c47a-4a2f-b824-574bed385201%40googlegroups.com](https://groups.google.com/d/msgid/elasticsearch/efcc9a1a-c47a-4a2f-b824-574bed385201%40googlegroups.com). For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout). ---
**Author:** ![system](https://us1.discourse-cdn.com/elastic/original/3X/1/a/1ac57faf039f6b580b3f104ef42a2a89e41014de.png) [@system](https://discuss.elastic.co/u/system)\ **Post date:** [July 6, 2017, 1:16am UTC](https://discuss.elastic.co/t/query-string-query-mini-language-vs-grammar-implementation/18539/4 "2017-07-06T01:16:47Z")