Convert Query-Context into Filter-Context

[mos]

Using ES 5.1.1 - imagine the following simple query:

  GET /bank/_search
    {
      "query": {
        "match": {
          "firstname": "Amber"
        }
      }
    }

This query shouldn't be executed as a query, but as a filter (speeding up things). I tried something like

GET /bank/_search
{
  "query": { 
    "bool": { 
     "filter": [ 
        { "term":  { "firstname": "Amber" }}
      ]
    }
  }
}

But this doesn't work and returns 0 results. Using ES 2.2 this worked with the old "filtered" keyword (instead of "bool"). But that's not allowed in 5.x (https://www.elastic.co/guide/en/elasticsearch/reference/5.1/query-dsl-filtered-query.html)

What is the simplest syntax to convert the query above into a filter-search?

[Mark_Harwood]

term queries do not use an Analyzer to process the text whereas match queries do.
So Amber won't be lower-cased (or whatever your analysis pipeline normally does)

Simply put the match query inside the bool/filter expression and not the term query.

[mos]

Thanks, Mark.You are right!

Still wondering why a syntax like this

GET /bank/_search
{
  "query": { 
    "bool": { 
     "filter":  
        { "match":  { "firstname": "Amber" }}
    }
  }
}

is required and not something like

GET /bank/_search
    {
      "filter": {
        "match": {
          "firstname": "Amber"
        }
      }
    }

Why need a filter always be executed inside a "query-context"?
Otherwise it would be much more straightforward. Any ideas for this design decision?

[Mark_Harwood]

@mos

Why need a filter always be executed inside a "query-context"?

The root query is just the place-marker for where we keep all the document selection criteria. Frequently criteria is complex and requires multiple levels of nested booleans and filters /queries. Having a single root to this tree structure can help unfold the various parts of the logic piece by piece in my experience but I can see for the simple use case it might seem verbose.