# Query string needs an excludes option

**URL:** <https://discuss.elastic.co/t/query-string-needs-an-excludes-option/166427>\
**Category:** Elasticsearch\
**Created:** [January 30, 2019, 8:21pm UTC](https://discuss.elastic.co/t/query-string-needs-an-excludes-option/166427 "2019-01-30T20:21:46Z")\
**Posts on this page:** 7\
**Page:** 1

<div class="post-metadata">

**Author:** ![maziyar](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/maziyar/32/18423_2.png) [@maziyar](https://discuss.elastic.co/u/maziyar)\
**Post date:** [January 30, 2019, 8:21pm UTC](https://discuss.elastic.co/t/query-string-needs-an-excludes-option/166427/1 "2019-01-30T20:21:46Z")

</div>

Hello,

I have been using `query_string` in my application which sits behind Swagger APIs and provides rest APIs for our researchers for a few years now. The power of `query_string` is undeniable. That is why it's the best choice to sit behind an API engine.

However, the absence of `excludes` feature will turn its greatest power to very dangerous scenarios where I cannot stop users to perform queries on some fields which I don't want them to search nor be able to see. (I can use `_source` to exclude the fields but still, they can see the rest of the document based on their query)

In all the documentation (all the versions) this is wrong:

```auto
GET /_search
{
    "query": {
        "query_string" : {
            "fields" : ["content", "name"],
            "query" : "this AND that"
        }
    }
}

```

This tells me the `fields` will be used to query. Which is not true at all where you can simply use the following:

```auto
GET /_search
{
    "query": {
        "query_string" : {
            "fields" : ["content", "name"],
            "query" : "secretField:TellMeMore!"
        }
    }
}

```

This should have been clear in the docs because I used it for 2 years without knowing `fields` didn't mean just those fields. (I am not talking about security and ACLs, but there are situations where you should have control over what to be searched and what to be retrieved.)

Can we please have this feature in `query_string` where we can simply use `excludes` to list some fields which should not be used in search? (I don't want to use mapping to make them not searchable, other APIs have the right to use those fields to search. I just want to be able to control my query.)

Many thanks for your time 🙂

PS:  
This question was raised 2 years ago, and the response that the user should come up with his own parser was not fair. Elasticsearch should first clarify the `fields` doesn't mean only those fields will be searchable. Also, it is only logical that this is much easier, cleaner, and more stable where Elasticsearch at its core ignore a list of fields rather than a user writes its own parser.

> [@Limit the flexibility of a query\_string query?](https://discuss.elastic.co/t/limit-the-flexibility-of-a-query-string-query/9975):
>
> I'd like to take advantage of the query string query to avoid the pain of parsing a user's search text. I want them to have pretty much all the powers that the parser provides including AND, OR, prefix, fuzzy etc. However, there are a couple limitations I'd like to impose: No leading wildcard (simple enough, that's an option on query\_string). The user should not be able to choose the fields to search in (e.g. "price:100" should not be allowed). Is there a way to do this with ES, or do I n…

---

<div class="post-metadata">

**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:** [January 30, 2019, 9:48pm UTC](https://discuss.elastic.co/t/query-string-needs-an-excludes-option/166427/2 "2019-01-30T21:48:40Z")

</div>

@jpountz WDYT?

---

<div class="post-metadata">

**Author:** ![jpountz](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/jpountz/32/45836_2.png) [@jpountz](https://discuss.elastic.co/u/jpountz)\
**Post date:** [January 31, 2019, 9:51am UTC](https://discuss.elastic.co/t/query-string-needs-an-excludes-option/166427/3 "2019-01-31T09:51:33Z")

</div>

`query_string` is not really meant to be exposed to end users. It has other drawbacks when it comes to exposing a query language to end users: it also allows very expensive queries and may fail in bad ways in case of mismatched parenthesis for instance. The `match` and `simple_query_string` are better query parsers for end user queries in my opinion. None of them allow changing the searched field in the query string.

---

<div class="post-metadata">

**Author:** ![maziyar](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/maziyar/32/18423_2.png) [@maziyar](https://discuss.elastic.co/u/maziyar)\
**Post date:** [January 31, 2019, 1:50pm UTC](https://discuss.elastic.co/t/query-string-needs-an-excludes-option/166427/4 "2019-01-31T13:50:21Z")

</div>

Hi @dadoonet and @jpountz and thanks for your time.

I've been aware of `simple_query_string` since its introduction and always wondered if it was possible to add the option to disable an inline searched field in `query_string` as well.

The only drawback that holds me from migrating to `simple_query_string` was/is that it requires changing all the `OR/AND` in our automated queries to flags(+/|) and also educate our users via changing documentation of APIs.

Are you aware that in the future it would be possible to also have `AND/OR` as an addition to the current flags in `simple_query_string`? This makes the transition simple and non-breaking.

Many thanks,

---

<div class="post-metadata">

**Author:** ![jpountz](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/jpountz/32/45836_2.png) [@jpountz](https://discuss.elastic.co/u/jpountz)\
**Post date:** [January 31, 2019, 2:54pm UTC](https://discuss.elastic.co/t/query-string-needs-an-excludes-option/166427/5 "2019-01-31T14:54:19Z")

</div>

`simple_query_string` avoids using keywords so that searching for the word "and" or "or" is more intuitive, although the `AND` and `OR` keywords are probably what most users are familiar with so I understand your point.

We don't have anything like that scheduled for the near future. Would you mind opening a feature request on the Github repo?

---

<div class="post-metadata">

**Author:** ![maziyar](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/maziyar/32/18423_2.png) [@maziyar](https://discuss.elastic.co/u/maziyar)\
**Post date:** [January 31, 2019, 4:02pm UTC](https://discuss.elastic.co/t/query-string-needs-an-excludes-option/166427/6 "2019-01-31T16:02:18Z")

</div>

With pleasure! Thanks again @jpountz for your time I really appreciate 🙂

---

<div class="post-metadata">

**Author:** ![system](https://us1.discourse-cdn.com/elastic/original/3X/1/a/1ac57faf039f6b580b3f104ef42a2a89e41014de.png) [@system](https://discuss.elastic.co/u/system)\
**Post date:** [February 28, 2019, 4:02pm UTC](https://discuss.elastic.co/t/query-string-needs-an-excludes-option/166427/7 "2019-02-28T16:02:20Z")

</div>

This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.