Do you remember our example with the percolator in Chapter 6, Beyond Searching? The assumption was that the user could generate a query, probably by using some kind of wizard, which was stored in ElasticSearch and used for matching documents. You already know that ElasticSearch has many possibilities and many kinds of queries, and sometimes it is difficult to tell if a query is correct or not. To help with this, ElasticSearch exposes the Validate API.
The Validate API is simple. Instead of sending the query to the _search endpoint, we send it to the _validate/query endpoint. And that's it. Let's look again at a query that we are already familiar with:
{
"bool" : {
"must" : {
"term" : {
"title" : "crime"
}
},
"should" : {
"range : {
"year" : {
"from" : 1900,
"to" : 2000
}
}
},
"must_not" : {
"term" : {
"otitle" : "nothing"
}
}
}
}This query was used twice in this book. Note that for validation we have omitted the query attribute and sent only the enclosed object. We know that everything is right with the query, but let's check it with the following command:
curl -XGET 'localhost:9200/library/_validate/query?pretty' -d @query.json
And of course, everything should be fine. So, let's look at the response from ElasticSearch:
{
"valid" : false,
"_shards" : {
"total" : 1,
"successful" : 1,
"failed" : 0
}
}Look at the valid attribute. It is set to false. Something went wrong. Let's execute the query validation once again with the explain parameter added in the query:
curl -XGET 'localhost:9200/library/_validate/query?pretty&explain' --data-binary @query.json
Now the result returned from ElasticSearch is more verbose:
{
"valid" : false,
"_shards" : {
"total" : 1,
"successful" : 1,
"failed" : 0
},
"explanations" : [ {
"index" : "library",
"valid" : false,
"error" : "org.elasticsearch.index.query.QueryParsingException: [library] Failed to parse; org.elasticsearch.common.jackson.core.JsonParseException: Illegal unquoted character ((CTRL-CHAR, code 10)): has to be escaped using backslash to be included in name
at [Source: [B@61e918c2; line: 9, column: 16]"
} ]
}Now everything is clear. In our example, we have improperly quoted the range attribute.
Note
You may be wondering why in our URL query we used the --data-binary parameter. This parameter properly preserves the new line character when sending a query to ElasticSearch. This means that the line and column number will be intact and it's easier to find errors. In the other cases, the –d parameter is more convenient, because it's shorter.
The Validate API can also detect other errors, for example, incorrect format of a number or other mapping-related issues. Unfortunately, for our application, it is not easy to detect what the problem is because of lack of structure in the error messages.