WARNING: The 2.x versions of Elasticsearch have passed their EOL dates. If you are running a 2.x version, we strongly advise you to upgrade.
This documentation is no longer maintained and may be removed. For the latest information, see the current Elasticsearch documentation.
Validating Queriesedit
Queries can become quite complex and, especially when combined with
different analyzers and field mappings, can become a bit difficult to follow.
The validate-query
API can be used to check whether a query is valid.
GET /gb/tweet/_validate/query { "query": { "tweet" : { "match" : "really powerful" } } }
The response to the preceding validate
request tells us that the query is
invalid:
{ "valid" : false, "_shards" : { "total" : 1, "successful" : 1, "failed" : 0 } }
Understanding Errorsedit
To find out why it is invalid, add the explain
parameter to the query
string:
Apparently, we’ve mixed up the type of query (match
) with the name
of the field (tweet
):
{ "valid" : false, "_shards" : { ... }, "explanations" : [ { "index" : "gb", "valid" : false, "error" : "org.elasticsearch.index.query.QueryParsingException: [gb] No query registered for [tweet]" } ] }
Understanding Queriesedit
Using the explain
parameter has the added advantage of returning
a human-readable description of the (valid) query, which can be useful for
understanding exactly how your query has been interpreted by Elasticsearch:
GET /_validate/query?explain { "query": { "match" : { "tweet" : "really powerful" } } }
An explanation
is returned for each index that we query, because each
index can have different mappings and analyzers:
{ "valid" : true, "_shards" : { ... }, "explanations" : [ { "index" : "us", "valid" : true, "explanation" : "tweet:really tweet:powerful" }, { "index" : "gb", "valid" : true, "explanation" : "tweet:realli tweet:power" } ] }
From the explanation
, you can see how the match
query for the query string
really powerful
has been rewritten as two single-term queries against
the tweet
field, one for each term.
Also, for the us
index, the two terms are really
and powerful
, while
for the gb
index, the terms are realli
and power
. The reason
for this is that we changed the tweet
field in the gb
index to use the
english
analyzer.
- Elasticsearch - The Definitive Guide:
- Foreword
- Preface
- Getting Started
- You Know, for Search…
- Installing and Running Elasticsearch
- Talking to Elasticsearch
- Document Oriented
- Finding Your Feet
- Indexing Employee Documents
- Retrieving a Document
- Search Lite
- Search with Query DSL
- More-Complicated Searches
- Full-Text Search
- Phrase Search
- Highlighting Our Searches
- Analytics
- Tutorial Conclusion
- Distributed Nature
- Next Steps
- Life Inside a Cluster
- Data In, Data Out
- What Is a Document?
- Document Metadata
- Indexing a Document
- Retrieving a Document
- Checking Whether a Document Exists
- Updating a Whole Document
- Creating a New Document
- Deleting a Document
- Dealing with Conflicts
- Optimistic Concurrency Control
- Partial Updates to Documents
- Retrieving Multiple Documents
- Cheaper in Bulk
- Distributed Document Store
- Searching—The Basic Tools
- Mapping and Analysis
- Full-Body Search
- Sorting and Relevance
- Distributed Search Execution
- Index Management
- Inside a Shard
- You Know, for Search…
- Search in Depth
- Structured Search
- Full-Text Search
- Multifield Search
- Proximity Matching
- Partial Matching
- Controlling Relevance
- Theory Behind Relevance Scoring
- Lucene’s Practical Scoring Function
- Query-Time Boosting
- Manipulating Relevance with Query Structure
- Not Quite Not
- Ignoring TF/IDF
- function_score Query
- Boosting by Popularity
- Boosting Filtered Subsets
- Random Scoring
- The Closer, The Better
- Understanding the price Clause
- Scoring with Scripts
- Pluggable Similarity Algorithms
- Changing Similarities
- Relevance Tuning Is the Last 10%
- Dealing with Human Language
- Aggregations
- Geolocation
- Modeling Your Data
- Administration, Monitoring, and Deployment