Revert "Add Autosense annotation for query dsl testing"

This commit is contained in:
Isabel Drost-Fromm 2016-05-17 20:55:56 +02:00
parent 5485d5c010
commit 20aafb1196
46 changed files with 866 additions and 1432 deletions

View File

@ -81,7 +81,7 @@ all documents where the `status` field contains the term `active`.
This first query assigns a score of `0` to all documents, as no scoring
query has been specified:
[source,js]
[source,json]
---------------------------------
GET _search
{
@ -101,7 +101,7 @@ GET _search
This `bool` query has a `match_all` query, which assigns a score of `1.0` to
all documents.
[source,js]
[source,json]
---------------------------------
GET _search
{
@ -125,7 +125,7 @@ This `constant_score` query behaves in exactly the same way as the second exampl
The `constant_score` query assigns a score of `1.0` to all documents matched
by the filter.
[source,js]
[source,json]
---------------------------------
GET _search
{

View File

@ -8,9 +8,7 @@ overall score.
[source,js]
--------------------------------------------------
GET /_search
{
"query": {
"boosting" : {
"positive" : {
"term" : {
@ -25,6 +23,4 @@ GET /_search
"negative_boost" : 0.2
}
}
}
--------------------------------------------------
// CONSOLE

View File

@ -70,9 +70,7 @@ In this example, words that have a document frequency greater than 0.1%
[source,js]
--------------------------------------------------
GET /_search
{
"query": {
"common": {
"body": {
"query": "this is bonsai cool",
@ -80,9 +78,7 @@ GET /_search
}
}
}
}
--------------------------------------------------
// CONSOLE
The number of terms which should match can be controlled with the
<<query-dsl-minimum-should-match,`minimum_should_match`>>
@ -94,9 +90,7 @@ all terms required:
[source,js]
--------------------------------------------------
GET /_search
{
"query": {
"common": {
"body": {
"query": "nelly the elephant as a cartoon",
@ -105,17 +99,13 @@ GET /_search
}
}
}
}
--------------------------------------------------
// CONSOLE
which is roughly equivalent to:
[source,js]
--------------------------------------------------
GET /_search
{
"query": {
"bool": {
"must": [
{ "term": { "body": "nelly"}},
@ -123,15 +113,13 @@ GET /_search
{ "term": { "body": "cartoon"}}
],
"should": [
{ "term": { "body": "the"}},
{ "term": { "body": "as"}},
{ "term": { "body": "the"}}
{ "term": { "body": "as"}}
{ "term": { "body": "a"}}
]
}
}
}
--------------------------------------------------
// CONSOLE
Alternatively use
<<query-dsl-minimum-should-match,`minimum_should_match`>>
@ -140,9 +128,7 @@ must be present, for instance:
[source,js]
--------------------------------------------------
GET /_search
{
"query": {
"common": {
"body": {
"query": "nelly the elephant as a cartoon",
@ -151,17 +137,13 @@ GET /_search
}
}
}
}
--------------------------------------------------
// CONSOLE
which is roughly equivalent to:
[source,js]
--------------------------------------------------
GET /_search
{
"query": {
"bool": {
"must": {
"bool": {
@ -174,15 +156,13 @@ GET /_search
}
},
"should": [
{ "term": { "body": "the"}},
{ "term": { "body": "as"}},
{ "term": { "body": "the"}}
{ "term": { "body": "as"}}
{ "term": { "body": "a"}}
]
}
}
}
--------------------------------------------------
// CONSOLE
minimum_should_match
@ -194,9 +174,7 @@ additional parameters (note the change in structure):
[source,js]
--------------------------------------------------
GET /_search
{
"query": {
"common": {
"body": {
"query": "nelly the elephant not as a cartoon",
@ -208,17 +186,13 @@ GET /_search
}
}
}
}
--------------------------------------------------
// CONSOLE
which is roughly equivalent to:
[source,js]
--------------------------------------------------
GET /_search
{
"query": {
"bool": {
"must": {
"bool": {
@ -243,9 +217,7 @@ GET /_search
}
}
}
}
--------------------------------------------------
// CONSOLE
In this case it means the high frequency terms have only an impact on
relevance when there are at least three of them. But the most
@ -255,9 +227,7 @@ for high frequency terms is when there are only high frequency terms:
[source,js]
--------------------------------------------------
GET /_search
{
"query": {
"common": {
"body": {
"query": "how not to be",
@ -269,17 +239,13 @@ GET /_search
}
}
}
}
--------------------------------------------------
// CONSOLE
which is roughly equivalent to:
[source,js]
--------------------------------------------------
GET /_search
{
"query": {
"bool": {
"should": [
{ "term": { "body": "how"}},
@ -290,9 +256,7 @@ GET /_search
"minimum_should_match": "3<50%"
}
}
}
--------------------------------------------------
// CONSOLE
The high frequency generated query is then slightly less restrictive
than with an `AND`.

View File

@ -7,9 +7,7 @@ filter. Maps to Lucene `ConstantScoreQuery`.
[source,js]
--------------------------------------------------
GET /_search
{
"query": {
"constant_score" : {
"filter" : {
"term" : { "user" : "kimchy"}
@ -17,6 +15,4 @@ GET /_search
"boost" : 1.2
}
}
}
--------------------------------------------------
// CONSOLE

View File

@ -27,9 +27,7 @@ This query maps to Lucene `DisjunctionMaxQuery`.
[source,js]
--------------------------------------------------
GET /_search
{
"query": {
"dis_max" : {
"tie_breaker" : 0.7,
"boost" : 1.2,
@ -43,6 +41,4 @@ GET /_search
]
}
}
}
--------------------------------------------------
// CONSOLE

View File

@ -5,14 +5,10 @@ Returns documents that have at least one non-`null` value in the original field:
[source,js]
--------------------------------------------------
GET /_search
{
"query": {
"exists" : { "field" : "user" }
}
}
--------------------------------------------------
// CONSOLE
For instance, these documents would all match the above query:
@ -81,9 +77,6 @@ clause as follows:
[source,js]
--------------------------------------------------
GET /_search
{
"query": {
"bool": {
"must_not": {
"exists": {
@ -91,10 +84,7 @@ GET /_search
}
}
}
}
}
--------------------------------------------------
// CONSOLE
This query returns documents that have no value in the user field.

View File

@ -14,20 +14,13 @@ by the query.
[source,js]
--------------------------------------------------
GET /_search
{
"query": {
"function_score": {
"query": {},
"boost": "5",
"random_score": {}, <1>
"boost_mode":"multiply"
}
}
"boost": "boost for the whole query",
"FUNCTION": {}, <1>
"boost_mode":"(multiply|replace|...)"
}
--------------------------------------------------
// CONSOLE
<1> See <<score-functions>> for a list of supported functions.
Furthermore, several functions can be combined. In this case one can
@ -36,35 +29,30 @@ given filtering query
[source,js]
--------------------------------------------------
GET /_search
{
"query": {
"function_score": {
"query": {},
"boost": "5", <1>
"boost": "boost for the whole query",
"functions": [
{
"filter": {},
"random_score": {}, <2>
"weight": 23
"FUNCTION": {}, <1>
"weight": number
},
{
"FUNCTION": {} <1>
},
{
"filter": {},
"weight": 42
"weight": number
}
],
"max_boost": 42,
"score_mode": "max",
"boost_mode": "multiply",
"min_score" : 42
}
}
"max_boost": number,
"score_mode": "(multiply|max|...)",
"boost_mode": "(multiply|replace|...)",
"min_score" : number
}
--------------------------------------------------
// CONSOLE
<1> Boost for the whole query.
<2> See <<score-functions>> for a list of supported functions.
<1> See <<score-functions>> for a list of supported functions.
NOTE: The scores produced by the filtering query of each function do not matter.
@ -471,7 +459,7 @@ the request would look like this:
[source,js]
--------------------------------------------------
GET /_search
GET _search
{
"query": {
"function_score": {

View File

@ -16,22 +16,16 @@ Here is a simple example:
[source,js]
--------------------------------------------------
GET /_search
{
"query": {
"fuzzy" : { "user" : "ki" }
}
}
--------------------------------------------------
// CONSOLE
Or with more advanced settings:
[source,js]
--------------------------------------------------
GET /_search
{
"query": {
"fuzzy" : {
"user" : {
"value" : "ki",
@ -42,9 +36,7 @@ GET /_search
}
}
}
}
--------------------------------------------------
// CONSOLE
[float]
===== Parameters
@ -70,4 +62,3 @@ WARNING: This query can be very heavy if `prefix_length` is set to `0` and if
`max_expansions` is set to a high number. It could result in every term in the
index being examined!

View File

@ -6,24 +6,6 @@ bounding box. Assuming the following indexed document:
[source,js]
--------------------------------------------------
PUT /my_locations
{
"mappings": {
"location": {
"properties": {
"pin": {
"properties": {
"location": {
"type": "geo_point"
}
}
}
}
}
}
}
PUT /my_locations/location/1
{
"pin" : {
"location" : {
@ -33,17 +15,13 @@ PUT /my_locations/location/1
}
}
--------------------------------------------------
// CONSOLE
// TESTSETUP
Then the following simple query can be executed with a
`geo_bounding_box` filter:
[source,js]
--------------------------------------------------
GET /_search
{
"query": {
"bool" : {
"must" : {
"match_all" : {}
@ -64,9 +42,7 @@ GET /_search
}
}
}
}
--------------------------------------------------
// CONSOLE
[float]
==== Query Options
@ -99,9 +75,7 @@ representation of the geo point, the filter can accept it as well:
[source,js]
--------------------------------------------------
GET /_search
{
"query": {
"bool" : {
"must" : {
"match_all" : {}
@ -122,9 +96,7 @@ GET /_search
}
}
}
}
--------------------------------------------------
// CONSOLE
[float]
===== Lat Lon As Array
@ -134,9 +106,7 @@ conform with http://geojson.org/[GeoJSON].
[source,js]
--------------------------------------------------
GET /_search
{
"query": {
"bool" : {
"must" : {
"match_all" : {}
@ -151,9 +121,7 @@ GET /_search
}
}
}
}
--------------------------------------------------
// CONSOLE
[float]
===== Lat Lon As String
@ -162,9 +130,7 @@ Format in `lat,lon`.
[source,js]
--------------------------------------------------
GET /_search
{
"query": {
"bool" : {
"must" : {
"match_all" : {}
@ -179,18 +145,14 @@ GET /_search
}
}
}
}
--------------------------------------------------
// CONSOLE
[float]
===== Geohash
[source,js]
--------------------------------------------------
GET /_search
{
"query": {
"bool" : {
"must" : {
"match_all" : {}
@ -205,9 +167,7 @@ GET /_search
}
}
}
}
--------------------------------------------------
// CONSOLE
[float]
==== Vertices
@ -221,9 +181,7 @@ values separately.
[source,js]
--------------------------------------------------
GET /_search
{
"query": {
"bool" : {
"must" : {
"match_all" : {}
@ -240,9 +198,7 @@ GET /_search
}
}
}
}
--------------------------------------------------
// CONSOLE
[float]
@ -271,9 +227,7 @@ are not supported. Here is an example:
[source,js]
--------------------------------------------------
GET /_search
{
"query": {
"bool" : {
"must" : {
"match_all" : {}
@ -295,9 +249,7 @@ GET /_search
}
}
}
}
--------------------------------------------------
// CONSOLE
[float]
==== Ignore Unmapped

View File

@ -2,29 +2,10 @@
=== Geo Distance Query
Filters documents that include only hits that exists within a specific
distance from a geo point. Assuming the following mapping and indexed
document:
distance from a geo point. Assuming the following indexed json:
[source,js]
--------------------------------------------------
PUT /my_locations
{
"mappings": {
"location": {
"properties": {
"pin": {
"properties": {
"location": {
"type": "geo_point"
}
}
}
}
}
}
}
PUT /my_locations/location/1
{
"pin" : {
"location" : {
@ -34,18 +15,13 @@ PUT /my_locations/location/1
}
}
--------------------------------------------------
// CONSOLE
// TESTSETUP
Then the following simple query can be executed with a `geo_distance`
filter:
[source,js]
--------------------------------------------------
GET /my_locations/location/_search
{
"query": {
"bool" : {
"must" : {
"match_all" : {}
@ -61,9 +37,7 @@ GET /my_locations/location/_search
}
}
}
}
--------------------------------------------------
// CONSOLE
[float]
==== Accepted Formats
@ -76,9 +50,7 @@ representation of the geo point, the filter can accept it as well:
[source,js]
--------------------------------------------------
GET /my_locations/location/_search
{
"query": {
"bool" : {
"must" : {
"match_all" : {}
@ -94,9 +66,7 @@ GET /my_locations/location/_search
}
}
}
}
--------------------------------------------------
// CONSOLE
[float]
===== Lat Lon As Array
@ -106,9 +76,7 @@ conform with http://geojson.org/[GeoJSON].
[source,js]
--------------------------------------------------
GET /my_locations/location/_search
{
"query": {
"bool" : {
"must" : {
"match_all" : {}
@ -121,10 +89,7 @@ GET /my_locations/location/_search
}
}
}
}
--------------------------------------------------
// CONSOLE
[float]
===== Lat Lon As String
@ -133,9 +98,7 @@ Format in `lat,lon`.
[source,js]
--------------------------------------------------
GET /my_locations/location/_search
{
"query": {
"bool" : {
"must" : {
"match_all" : {}
@ -148,18 +111,14 @@ GET /my_locations/location/_search
}
}
}
}
--------------------------------------------------
// CONSOLE
[float]
===== Geohash
[source,js]
--------------------------------------------------
GET /my_locations/location/_search
{
"query": {
"bool" : {
"must" : {
"match_all" : {}
@ -172,9 +131,7 @@ GET /my_locations/location/_search
}
}
}
}
--------------------------------------------------
// CONSOLE
[float]
==== Options

View File

@ -5,9 +5,7 @@ Filters documents that exists within a range from a specific point:
[source,js]
--------------------------------------------------
GET /_search
{
"query": {
"bool" : {
"must" : {
"match_all" : {}
@ -24,9 +22,7 @@ GET /_search
}
}
}
}
--------------------------------------------------
// CONSOLE
Supports the same point location parameter and query options as the
<<query-dsl-geo-distance-query,geo_distance>>

View File

@ -6,11 +6,9 @@ points. Here is an example:
[source,js]
--------------------------------------------------
GET /_search
{
"query": {
"bool" : {
"must" : {
"query" : {
"match_all" : {}
},
"filter" : {
@ -26,9 +24,7 @@ GET /_search
}
}
}
}
--------------------------------------------------
// CONSOLE
[float]
==== Query Options
@ -57,9 +53,7 @@ conform with http://geojson.org/[GeoJSON].
[source,js]
--------------------------------------------------
GET /_search
{
"query": {
"bool" : {
"must" : {
"match_all" : {}
@ -77,9 +71,7 @@ GET /_search
}
}
}
}
--------------------------------------------------
// CONSOLE
[float]
===== Lat Lon as String
@ -88,9 +80,7 @@ Format in `lat,lon`.
[source,js]
--------------------------------------------------
GET /_search
{
"query": {
"bool" : {
"must" : {
"match_all" : {}
@ -108,18 +98,14 @@ GET /_search
}
}
}
}
--------------------------------------------------
// CONSOLE
[float]
===== Geohash
[source,js]
--------------------------------------------------
GET /_search
{
"query": {
"bool" : {
"must" : {
"match_all" : {}
@ -137,9 +123,7 @@ GET /_search
}
}
}
}
--------------------------------------------------
// CONSOLE
[float]
==== geo_point Type

View File

@ -38,7 +38,6 @@ The following query will find the point using the Elasticsearch's
[source,js]
--------------------------------------------------
GET /_search
{
"query":{
"bool": {
@ -60,7 +59,6 @@ GET /_search
}
}
--------------------------------------------------
// CONSOLE
==== Pre-Indexed Shape
@ -83,9 +81,7 @@ shape:
[source,js]
--------------------------------------------------
GET /_search
{
"query": {
"bool": {
"must": {
"match_all": {}
@ -104,9 +100,7 @@ GET /_search
}
}
}
}
--------------------------------------------------
// CONSOLE
==== Spatial Relations

View File

@ -13,7 +13,6 @@ setting the `geohash_prefix` option:
[source,js]
--------------------------------------------------
PUT /my_index
{
"mappings" : {
"location": {
@ -29,8 +28,6 @@ PUT /my_index
}
}
--------------------------------------------------
// CONSOLE
// TESTSETUP
The geohash cell can defined by all formats of `geo_points`. If such a cell is
defined by a latitude and longitude pair the size of the cell needs to be
@ -45,9 +42,7 @@ next to the given cell.
[source,js]
--------------------------------------------------
GET /_search
{
"query": {
"bool" : {
"must" : {
"match_all" : {}
@ -64,9 +59,7 @@ GET /_search
}
}
}
}
--------------------------------------------------
// CONSOLE
[float]
==== Ignore Unmapped

View File

@ -7,9 +7,7 @@ an example:
[source,js]
--------------------------------------------------
GET /_search
{
"query": {
"has_child" : {
"type" : "blog_tag",
"query" : {
@ -19,9 +17,7 @@ GET /_search
}
}
}
}
--------------------------------------------------
// CONSOLE
[float]
==== Scoring capabilities
@ -36,9 +32,7 @@ inside the `has_child` query:
[source,js]
--------------------------------------------------
GET /_search
{
"query": {
"has_child" : {
"type" : "blog_tag",
"score_mode" : "min",
@ -49,9 +43,7 @@ GET /_search
}
}
}
}
--------------------------------------------------
// CONSOLE
[float]
==== Min/Max Children
@ -62,9 +54,7 @@ a match:
[source,js]
--------------------------------------------------
GET /_search
{
"query": {
"has_child" : {
"type" : "blog_tag",
"score_mode" : "min",
@ -77,9 +67,7 @@ GET /_search
}
}
}
}
--------------------------------------------------
// CONSOLE
<1> Both `min_children` and `max_children` are optional.
The `min_children` and `max_children` parameters can be combined with

View File

@ -9,9 +9,7 @@ in the same manner as the `has_child` query.
[source,js]
--------------------------------------------------
GET /_search
{
"query": {
"has_parent" : {
"parent_type" : "blog",
"query" : {
@ -21,9 +19,7 @@ GET /_search
}
}
}
}
--------------------------------------------------
// CONSOLE
[float]
==== Scoring capabilities
@ -38,9 +34,7 @@ matching parent document. The score mode can be specified with the
[source,js]
--------------------------------------------------
GET /_search
{
"query": {
"has_parent" : {
"parent_type" : "blog",
"score" : true,
@ -51,9 +45,7 @@ GET /_search
}
}
}
}
--------------------------------------------------
// CONSOLE
[float]
==== Ignore Unmapped

View File

@ -6,17 +6,13 @@ uses the <<mapping-uid-field,_uid>> field.
[source,js]
--------------------------------------------------
GET /_search
{
"query": {
"ids" : {
"type" : "my_type",
"values" : ["1", "4", "100"]
}
}
}
--------------------------------------------------
// CONSOLE
The `type` is optional and can be omitted, and can also accept an array
of values. If no type is specified, all types defined in the index mapping are tried.

View File

@ -9,18 +9,18 @@ on the list, the alternative `no_match_query` is executed.
[source,js]
--------------------------------------------------
GET /_search
{
"query": {
"indices" : {
"indices" : ["index1", "index2"],
"query" : { "term" : { "tag" : "wow" } },
"no_match_query" : { "term" : { "tag" : "kow" } }
"query" : {
"term" : { "tag" : "wow" }
},
"no_match_query" : {
"term" : { "tag" : "kow" }
}
}
}
--------------------------------------------------
// CONSOLE
You can use the `index` field to provide a single index.

View File

@ -6,27 +6,15 @@ of `1.0`.
[source,js]
--------------------------------------------------
GET /_search
{
"query": {
"match_all": {}
}
}
{ "match_all": {} }
--------------------------------------------------
// CONSOLE
The `_score` can be changed with the `boost` parameter:
[source,js]
--------------------------------------------------
GET /_search
{
"query": {
"match_all": { "boost" : 1.2 }
}
}
{ "match_all": { "boost" : 1.2 }}
--------------------------------------------------
// CONSOLE
[[query-dsl-match-none-query]]
[float]
@ -36,11 +24,5 @@ This is the inverse of the `match_all` query, which matches no documents.
[source,js]
--------------------------------------------------
GET /_search
{
"query": {
"match_none": {}
}
}
{ "match_none": {} }
--------------------------------------------------
// CONSOLE

View File

@ -6,16 +6,12 @@ allows for prefix matches on the last term in the text. For example:
[source,js]
--------------------------------------------------
GET /_search
{
"query": {
"match_phrase_prefix" : {
"message" : "quick brown f"
}
}
}
--------------------------------------------------
// CONSOLE
It accepts the same parameters as the phrase type. In addition, it also
accepts a `max_expansions` parameter (default `50`) that can control to how
@ -25,9 +21,7 @@ example:
[source,js]
--------------------------------------------------
GET /_search
{
"query": {
"match_phrase_prefix" : {
"message" : {
"query" : "quick brown f",
@ -35,9 +29,7 @@ GET /_search
}
}
}
}
--------------------------------------------------
// CONSOLE
[IMPORTANT]
===================================================

View File

@ -6,16 +6,12 @@ out of the analyzed text. For example:
[source,js]
--------------------------------------------------
GET /_search
{
"query": {
"match_phrase" : {
"message" : "this is a test"
}
}
}
--------------------------------------------------
// CONSOLE
A phrase query matches terms up to a configurable `slop`
(which defaults to 0) in any order. Transposed terms have a slop of 2.
@ -26,9 +22,7 @@ definition, or the default search analyzer, for example:
[source,js]
--------------------------------------------------
GET /_search
{
"query": {
"match_phrase" : {
"message" : {
"query" : "this is a test",
@ -36,6 +30,4 @@ GET /_search
}
}
}
}
--------------------------------------------------
// CONSOLE

View File

@ -7,16 +7,12 @@ them, and constructs a query. For example:
[source,js]
--------------------------------------------------
GET /_search
{
"query": {
"match" : {
"message" : "this is a test"
}
}
}
--------------------------------------------------
// CONSOLE
Note, `message` is the name of a field, you can substitute the name of
any field (including `_all`) instead.
@ -61,9 +57,7 @@ change in structure, `message` is the field name):
[source,js]
--------------------------------------------------
GET /_search
{
"query": {
"match" : {
"message" : {
"query" : "this is a test",
@ -71,9 +65,7 @@ GET /_search
}
}
}
}
--------------------------------------------------
// CONSOLE
[[query-dsl-match-query-zero]]
===== Zero terms query
@ -84,9 +76,7 @@ change that the `zero_terms_query` option can be used, which accepts
[source,js]
--------------------------------------------------
GET /_search
{
"query": {
"match" : {
"message" : {
"query" : "to be or not to be",
@ -95,9 +85,7 @@ GET /_search
}
}
}
}
--------------------------------------------------
// CONSOLE
[[query-dsl-match-query-cutoff]]
===== Cutoff frequency
@ -125,9 +113,7 @@ Here is an example showing a query composed of stopwords exclusively:
[source,js]
--------------------------------------------------
GET /_search
{
"query": {
"match" : {
"message" : {
"query" : "to be or not to be",
@ -135,9 +121,8 @@ GET /_search
}
}
}
}
--------------------------------------------------
// CONSOLE
IMPORTANT: The `cutoff_frequency` option operates on a per-shard-level. This means
that when trying it out on test indexes with low document numbers you

View File

@ -15,9 +15,7 @@ fields, limiting the number of selected terms to 12.
[source,js]
--------------------------------------------------
GET /_search
{
"query": {
"more_like_this" : {
"fields" : ["title", "description"],
"like" : "Once upon a time",
@ -25,9 +23,7 @@ GET /_search
"max_query_terms" : 12
}
}
}
--------------------------------------------------
// CONSOLE
A more complicated use case consists of mixing texts with documents already
existing in the index. In this case, the syntax to specify a document is
@ -35,9 +31,7 @@ similar to the one used in the <<docs-multi-get,Multi GET API>>.
[source,js]
--------------------------------------------------
GET /_search
{
"query": {
"more_like_this" : {
"fields" : ["title", "description"],
"like" : [
@ -57,9 +51,7 @@ GET /_search
"max_query_terms" : 12
}
}
}
--------------------------------------------------
// CONSOLE
Finally, users can mix some texts, a chosen set of documents but also provide
documents not necessarily present in the index. To provide documents not
@ -67,9 +59,7 @@ present in the index, the syntax is similar to <<docs-termvectors-artificial-doc
[source,js]
--------------------------------------------------
GET /_search
{
"query": {
"more_like_this" : {
"fields" : ["name.first", "name.last"],
"like" : [
@ -94,9 +84,7 @@ GET /_search
"max_query_terms" : 12
}
}
}
--------------------------------------------------
// CONSOLE
==== How it Works
@ -123,8 +111,7 @@ default, but there will be no speed up on analysis for these fields.
[source,js]
--------------------------------------------------
PUT /imdb
{
curl -s -XPUT 'http://localhost:9200/imdb/' -d '{
"mappings": {
"movies": {
"properties": {
@ -150,7 +137,6 @@ PUT /imdb
}
}
--------------------------------------------------
// CONSOLE
==== Parameters

View File

@ -6,17 +6,13 @@ to allow multi-field queries:
[source,js]
--------------------------------------------------
GET /_search
{
"query": {
"multi_match" : {
"query": "this is a test", <1>
"fields": [ "subject", "message" ] <2>
}
}
}
--------------------------------------------------
// CONSOLE
<1> The query string.
<2> The fields to be queried.
@ -27,35 +23,26 @@ Fields can be specified with wildcards, eg:
[source,js]
--------------------------------------------------
GET /_search
{
"query": {
"multi_match" : {
"query": "Will Smith",
"fields": [ "title", "*_name" ] <1>
}
}
}
--------------------------------------------------
// CONSOLE
<1> Query the `title`, `first_name` and `last_name` fields.
Individual fields can be boosted with the caret (`^`) notation:
[source,js]
--------------------------------------------------
GET /_search
{
"query": {
"multi_match" : {
"query" : "this is a test",
"fields" : [ "subject^3", "message" ] <1>
}
}
}
--------------------------------------------------
// CONSOLE
<1> The `subject` field is three times as important as the `message` field.
[[multi-match-types]]
@ -95,9 +82,7 @@ find the single best matching field. For instance, this query:
[source,js]
--------------------------------------------------
GET /_search
{
"query": {
"multi_match" : {
"query": "brown fox",
"type": "best_fields",
@ -105,17 +90,13 @@ GET /_search
"tie_breaker": 0.3
}
}
}
--------------------------------------------------
// CONSOLE
would be executed as:
[source,js]
--------------------------------------------------
GET /_search
{
"query": {
"dis_max": {
"queries": [
{ "match": { "subject": "brown fox" }},
@ -124,9 +105,7 @@ GET /_search
"tie_breaker": 0.3
}
}
}
--------------------------------------------------
// CONSOLE
Normally the `best_fields` type uses the score of the *single* best matching
field, but if `tie_breaker` is specified, then it calculates the score as
@ -153,9 +132,7 @@ Take this query for example:
[source,js]
--------------------------------------------------
GET /_search
{
"query": {
"multi_match" : {
"query": "Will Smith",
"type": "best_fields",
@ -163,10 +140,7 @@ GET /_search
"operator": "and" <1>
}
}
}
--------------------------------------------------
// CONSOLE
<1> All terms must be present.
This query is executed as:
@ -196,26 +170,20 @@ This query:
[source,js]
--------------------------------------------------
GET /_search
{
"query": {
"multi_match" : {
"query": "quick brown fox",
"type": "most_fields",
"fields": [ "title", "title.original", "title.shingles" ]
}
}
}
--------------------------------------------------
// CONSOLE
would be executed as:
[source,js]
--------------------------------------------------
GET /_search
{
"query": {
"bool": {
"should": [
{ "match": { "title": "quick brown fox" }},
@ -224,9 +192,7 @@ GET /_search
]
}
}
}
--------------------------------------------------
// CONSOLE
The score from each `match` clause is added together, then divided by the
number of `match` clauses.
@ -246,26 +212,20 @@ but they use a `match_phrase` or `match_phrase_prefix` query instead of a
This query:
[source,js]
--------------------------------------------------
GET /_search
{
"query": {
"multi_match" : {
"query": "quick brown f",
"type": "phrase_prefix",
"fields": [ "subject", "message" ]
}
}
}
--------------------------------------------------
// CONSOLE
would be executed as:
[source,js]
--------------------------------------------------
GET /_search
{
"query": {
"dis_max": {
"queries": [
{ "match_phrase_prefix": { "subject": "quick brown f" }},
@ -273,9 +233,7 @@ GET /_search
]
}
}
}
--------------------------------------------------
// CONSOLE
Also, accepts `analyzer`, `boost`, `slop` and `zero_terms_query` as explained
in <<query-dsl-match-query>>. Type `phrase_prefix` additionally accepts
@ -330,9 +288,7 @@ A query like:
[source,js]
--------------------------------------------------
GET /_search
{
"query": {
"multi_match" : {
"query": "Will Smith",
"type": "cross_fields",
@ -340,9 +296,7 @@ GET /_search
"operator": "and"
}
}
}
--------------------------------------------------
// CONSOLE
is executed as:
@ -390,9 +344,7 @@ both use an `edge_ngram` analyzer, this query:
[source,js]
--------------------------------------------------
GET /_search
{
"query": {
"multi_match" : {
"query": "Jon",
"type": "cross_fields",
@ -402,9 +354,7 @@ GET /_search
]
}
}
}
--------------------------------------------------
// CONSOLE
would be executed as:
@ -429,9 +379,7 @@ parameter to just one of them:
[source,js]
--------------------------------------------------
GET /_search
{
"query": {
"bool": {
"should": [
{
@ -452,10 +400,7 @@ GET /_search
]
}
}
}
--------------------------------------------------
// CONSOLE
<1> Either `will` or `smith` must be present in either of the `first`
or `last` fields
@ -464,9 +409,7 @@ parameter in the query.
[source,js]
--------------------------------------------------
GET /_search
{
"query": {
"multi_match" : {
"query": "Jon",
"type": "cross_fields",
@ -474,10 +417,7 @@ GET /_search
"fields": [ "first", "last", "*.edge" ]
}
}
}
--------------------------------------------------
// CONSOLE
<1> Use the `standard` analyzer for all fields.
which will be executed as:

View File

@ -10,9 +10,7 @@ will work with:
[source,js]
--------------------------------------------------
PUT /my_index
{
"mappings": {
"type1" : {
"properties" : {
"obj1" : {
@ -21,34 +19,31 @@ PUT /my_index
}
}
}
}
--------------------------------------------------
// CONSOLE
// TESTSETUP
And here is a sample nested query usage:
[source,js]
--------------------------------------------------
GET /_search
{
"query": {
"nested" : {
"path" : "obj1",
"score_mode" : "avg",
"query" : {
"bool" : {
"must" : [
{ "match" : {"obj1.name" : "blue"} },
{ "range" : {"obj1.count" : {"gt" : 5}} }
{
"match" : {"obj1.name" : "blue"}
},
{
"range" : {"obj1.count" : {"gt" : 5}}
}
]
}
}
}
}
}
--------------------------------------------------
// CONSOLE
The query `path` points to the nested object path, and the `query`
includes the query that will run on the nested docs matching the

View File

@ -3,48 +3,17 @@
added[5.0.0]
The `parent_id` query can be used to find child documents which belong to a
particular parent. Given the following mapping definition:
The `parent_id` query can be used to find child documents which belong to a particular parent:
[source,js]
--------------------------------------------------
PUT /my_index
{
"mappings": {
"blog_post": {
"properties": {
"name": {
"type": "keyword"
}
}
},
"blog_tag": {
"_parent": {
"type": "blog_post"
},
"_routing": {
"required": true
}
}
}
}
--------------------------------------------------
// CONSOLE
// TESTSETUP
[source,js]
--------------------------------------------------
GET /_search
{
"query": {
"parent_id" : {
"type" : "blog_tag",
"id" : "1"
}
}
}
--------------------------------------------------
// CONSOLE
The above is functionally equivalent to using the following
<<query-dsl-has-parent-query, `has_parent`>> query, but performs
@ -52,11 +21,9 @@ better as it does not need to do a join:
[source,js]
--------------------------------------------------
GET /my_index/_search
{
"query": {
"has_parent": {
"type": "blog_post",
"type": "blog",
"query": {
"term": {
"_id": "1"
@ -64,9 +31,7 @@ GET /my_index/_search
}
}
}
}
--------------------------------------------------
// CONSOLE
==== Parameters

View File

@ -13,7 +13,7 @@ Create an index with two mappings:
[source,js]
--------------------------------------------------
PUT /my-index
curl -XPUT "http://localhost:9200/my-index" -d'
{
"mappings": {
"doctype": {
@ -31,9 +31,8 @@ PUT /my-index
}
}
}
}
}'
--------------------------------------------------
// CONSOLE
The `doctype` mapping is the mapping used to preprocess
the document defined in the `percolator` query before it
@ -51,24 +50,20 @@ Register a query in the percolator:
[source,js]
--------------------------------------------------
PUT /my-index/queries/1
{
curl -XPUT 'localhost:9200/my-index/queries/1' -d '{
"query" : {
"match" : {
"message" : "bonsai tree"
}
}
}
}'
--------------------------------------------------
// CONSOLE
// TEST[continued]
Match a document to the registered percolator queries:
[source,js]
--------------------------------------------------
GET /my-index/_search
{
curl -XGET 'localhost:9200/my-index/_search' -d '{
"query" : {
"percolate" : {
"field" : "query",
@ -78,10 +73,8 @@ GET /my-index/_search
}
}
}
}
}'
--------------------------------------------------
// CONSOLE
// TEST[continued]
The above request will yield the following response:
@ -158,13 +151,12 @@ Index the document we want to percolate:
[source,js]
--------------------------------------------------
PUT /my-index/message/1
curl -XPUT "http://localhost:9200/my-index/message/1" -d'
{
"message" : "A new bonsai tree in the office"
}
}'
--------------------------------------------------
// CONSOLE
// TEST[continued]
Index response:
[source,js]
@ -187,7 +179,7 @@ Percolating an existing document, using the index response as basis to build to
[source,js]
--------------------------------------------------
GET /my-index/_search
curl -XGET "http://localhost:9200/my-index/_search" -d'
{
"query" : {
"percolate" : {
@ -199,10 +191,8 @@ GET /my-index/_search
"version" : 1 <1>
}
}
}
}'
--------------------------------------------------
// CONSOLE
// TEST[continued]
<1> The version is optional, but useful in certain cases. We can then ensure that we are try to percolate
the document we just have indexed. A change may be made after we have indexed, and if that is the
@ -226,39 +216,35 @@ Save a query:
[source,js]
--------------------------------------------------
PUT /my-index/queries/1
curl -XPUT "http://localhost:9200/my-index/queries/1" -d'
{
"query" : {
"match" : {
"message" : "brown fox"
}
}
}
}'
--------------------------------------------------
// CONSOLE
// TEST[continued]
Save another query:
[source,js]
--------------------------------------------------
PUT /my-index/queries/2
curl -XPUT "http://localhost:9200/my-index/queries/2" -d'
{
"query" : {
"match" : {
"message" : "lazy dog"
}
}
}
}'
--------------------------------------------------
// CONSOLE
// TEST[continued]
Execute a search request with the `percolate` query and highlighting enabled:
[source,js]
--------------------------------------------------
GET /my-index/_search
curl -XGET "http://localhost:9200/my-index/_search" -d'
{
"query" : {
"percolate" : {
@ -274,10 +260,8 @@ GET /my-index/_search
"message": {}
}
}
}
}'
--------------------------------------------------
// CONSOLE
// TEST[continued]
This will yield the following response.

View File

@ -8,37 +8,28 @@ that starts with `ki`:
[source,js]
--------------------------------------------------
GET /_search
{ "query": {
{
"prefix" : { "user" : "ki" }
}
}
--------------------------------------------------
// CONSOLE
A boost can also be associated with the query:
[source,js]
--------------------------------------------------
GET /_search
{ "query": {
{
"prefix" : { "user" : { "value" : "ki", "boost" : 2.0 } }
}
}
--------------------------------------------------
// CONSOLE
Or :
[source,js]
--------------------------------------------------
GET /_search
{ "query": {
{
"prefix" : { "user" : { "prefix" : "ki", "boost" : 2.0 } }
}
}
--------------------------------------------------
// CONSOLE
This multi term query allows you to control how it gets rewritten using the
<<query-dsl-multi-term-rewrite,rewrite>>

View File

@ -6,17 +6,13 @@ an example:
[source,js]
--------------------------------------------------
GET /_search
{
"query": {
"query_string" : {
"default_field" : "content",
"query" : "this AND that OR thus"
}
}
}
--------------------------------------------------
// CONSOLE
The `query_string` top level parameters include:
@ -117,33 +113,25 @@ For example, the following query
[source,js]
--------------------------------------------------
GET /_search
{
"query": {
"query_string" : {
"fields" : ["content", "name"],
"query" : "this AND that"
}
}
}
--------------------------------------------------
// CONSOLE
matches the same words as
[source,js]
--------------------------------------------------
GET /_search
{
"query": {
"query_string": {
"query": "(content:this OR name:this) AND (content:that OR name:that)"
}
}
}
--------------------------------------------------
// CONSOLE
Since several queries are generated from the individual search terms,
combining them can be automatically done using either a `dis_max` query or a
@ -152,18 +140,14 @@ notation):
[source,js]
--------------------------------------------------
GET /_search
{
"query": {
"query_string" : {
"fields" : ["content", "name^5"],
"query" : "this AND that OR thus",
"use_dis_max" : true
}
}
}
--------------------------------------------------
// CONSOLE
Simple wildcard can also be used to search "within" specific inner
elements of the document. For example, if we have a `city` object with
@ -172,18 +156,14 @@ search on all "city" fields:
[source,js]
--------------------------------------------------
GET /_search
{
"query": {
"query_string" : {
"fields" : ["city.*"],
"query" : "this AND that OR thus",
"use_dis_max" : true
}
}
}
--------------------------------------------------
// CONSOLE
Another option is to provide the wildcard fields search in the query
string itself (properly escaping the `*` sign), for example:
@ -208,17 +188,13 @@ introduced fields included). For example:
[source,js]
--------------------------------------------------
GET /_search
{
"query": {
"query_string" : {
"fields" : ["content", "name.*^5"],
"query" : "this AND that OR thus",
"use_dis_max" : true
}
}
}
--------------------------------------------------
// CONSOLE
include::query-string-syntax.asciidoc[]

View File

@ -47,7 +47,7 @@ conditions are met:
[source,js]
------------------------------------
GET /_search
GET _search
{
"query": { <1>
"bool": { <2>
@ -63,7 +63,6 @@ GET /_search
}
}
------------------------------------
// CONSOLE
<1> The `query` parameter indicates query context.
<2> The `bool` and two `match` clauses are used in query context,
which means that they are used to score how well each document

View File

@ -9,9 +9,7 @@ a `NumericRangeQuery`. The following example returns all documents where
[source,js]
--------------------------------------------------
GET _search
{
"query": {
"range" : {
"age" : {
"gte" : 10,
@ -20,9 +18,7 @@ GET _search
}
}
}
}
--------------------------------------------------
// CONSOLE
The `range` query accepts the following parameters:
@ -42,9 +38,7 @@ specified using <<date-math>>:
[source,js]
--------------------------------------------------
GET _search
{
"query": {
"range" : {
"date" : {
"gte" : "now-1d/d",
@ -52,9 +46,7 @@ GET _search
}
}
}
}
--------------------------------------------------
// CONSOLE
===== Date math and rounding
@ -94,9 +86,7 @@ passing the `format` parameter to the `range` query:
[source,js]
--------------------------------------------------
GET _search
{
"query": {
"range" : {
"born" : {
"gte": "01/01/2012",
@ -105,9 +95,7 @@ GET _search
}
}
}
}
--------------------------------------------------
// CONSOLE
===== Time zone in range queries
@ -117,9 +105,7 @@ accepts it), or it can be specified as the `time_zone` parameter:
[source,js]
--------------------------------------------------
GET _search
{
"query": {
"range" : {
"timestamp" : {
"gte": "2015-01-01 00:00:00", <1>
@ -128,8 +114,6 @@ GET _search
}
}
}
}
--------------------------------------------------
// CONSOLE
<1> This date will be converted to `2014-12-31T23:00:00 UTC`.
<2> `now` is not affected by the `time_zone` parameter (dates must be stored as UTC).

View File

@ -15,24 +15,18 @@ matchers like `.*?+` will mostly lower performance.
[source,js]
--------------------------------------------------
GET /_search
{
"query": {
"regexp":{
"name.first": "s.*y"
}
}
}
--------------------------------------------------
// CONSOLE
Boosting is also supported
[source,js]
--------------------------------------------------
GET /_search
{
"query": {
"regexp":{
"name.first":{
"value":"s.*y",
@ -40,17 +34,13 @@ GET /_search
}
}
}
}
--------------------------------------------------
// CONSOLE
You can also use special flags
[source,js]
--------------------------------------------------
GET /_search
{
"query": {
"regexp":{
"name.first": {
"value": "s.*y",
@ -58,9 +48,7 @@ GET /_search
}
}
}
}
--------------------------------------------------
// CONSOLE
Possible flags are `ALL` (default), `ANYSTRING`, `COMPLEMENT`,
`EMPTY`, `INTERSECTION`, `INTERVAL`, or `NONE`. Please check the
@ -76,9 +64,7 @@ this limit to allow more complex regular expressions to execute.
[source,js]
--------------------------------------------------
GET /_search
{
"query": {
"regexp":{
"name.first": {
"value": "s.*y",
@ -87,8 +73,7 @@ GET /_search
}
}
}
}
--------------------------------------------------
// CONSOLE
include::regexp-syntax.asciidoc[]

View File

@ -7,20 +7,17 @@ context, for example:
[source,js]
----------------------------------------------
GET /_search
{
"query": {
"bool" : {
"must" : {
...
},
"filter" : {
"script" : {
"script" : "doc['num1'].value > 1"
}
}
}
}
}
----------------------------------------------
// CONSOLE
[float]
==== Custom Parameters
@ -31,14 +28,14 @@ to use the ability to pass parameters to the script itself, for example:
[source,js]
----------------------------------------------
GET /_search
{
"query": {
"bool" : {
"must" : {
...
},
"filter" : {
"script" : {
"script" : {
"inline" : "doc['num1'].value > param1",
"inline" : "doc['num1'].value > param1"
"params" : {
"param1" : 5
}
@ -46,8 +43,5 @@ GET /_search
}
}
}
}
}
----------------------------------------------
// CONSOLE

View File

@ -8,9 +8,7 @@ an example:
[source,js]
--------------------------------------------------
GET /_search
{
"query": {
"simple_query_string" : {
"query": "\"fried eggs\" +(eggplant | potato) -frittata",
"analyzer": "snowball",
@ -18,9 +16,7 @@ GET /_search
"default_operator": "and"
}
}
}
--------------------------------------------------
// CONSOLE
The `simple_query_string` top level parameters include:
@ -98,17 +94,13 @@ introduced fields included). For example:
[source,js]
--------------------------------------------------
GET /_search
{
"query": {
"simple_query_string" : {
"fields" : ["content", "name.*^5"],
"query" : "foo bar baz"
}
}
}
--------------------------------------------------
// CONSOLE
[float]
==== Flags
@ -118,17 +110,13 @@ should be enabled. It is specified as a `|`-delimited string with the
[source,js]
--------------------------------------------------
GET /_search
{
"query": {
"simple_query_string" : {
"query" : "foo | bar + baz*",
"flags" : "OR|AND|PREFIX"
}
}
}
--------------------------------------------------
// CONSOLE
The available flags are: `ALL`, `NONE`, `AND`, `OR`, `NOT`, `PREFIX`, `PHRASE`,
`PRECEDENCE`, `ESCAPE`, `WHITESPACE`, `FUZZY`, `NEAR`, and `SLOP`.

View File

@ -6,9 +6,7 @@ query maps to Lucene `SpanContainingQuery`. Here is an example:
[source,js]
--------------------------------------------------
GET /_search
{
"query": {
"span_containing" : {
"little" : {
"span_term" : { "field1" : "foo" }
@ -25,9 +23,7 @@ GET /_search
}
}
}
}
--------------------------------------------------
// CONSOLE
The `big` and `little` clauses can be any span type query. Matching
spans from `big` that contain matches from `little` are returned.

View File

@ -6,9 +6,7 @@ to Lucene `SpanFirstQuery`. Here is an example:
[source,js]
--------------------------------------------------
GET /_search
{
"query": {
"span_first" : {
"match" : {
"span_term" : { "user" : "kimchy" }
@ -16,9 +14,7 @@ GET /_search
"end" : 3
}
}
}
--------------------------------------------------
// CONSOLE
The `match` clause can be any other span type query. The `end` controls
the maximum end position permitted in a match.

View File

@ -7,32 +7,24 @@ it can be nested. Example:
[source,js]
--------------------------------------------------
GET /_search
{
"query": {
"span_multi":{
"match":{
"prefix" : { "user" : { "value" : "ki" } }
}
}
}
}
--------------------------------------------------
// CONSOLE
A boost can also be associated with the query:
[source,js]
--------------------------------------------------
GET /_search
{
"query": {
"span_multi":{
"match":{
"prefix" : { "user" : { "value" : "ki", "boost" : 1.08 } }
}
}
}
}
--------------------------------------------------
// CONSOLE

View File

@ -8,9 +8,7 @@ matches are required to be in-order. The span near query maps to Lucene
[source,js]
--------------------------------------------------
GET /_search
{
"query": {
"span_near" : {
"clauses" : [
{ "span_term" : { "field" : "value1" } },
@ -21,9 +19,7 @@ GET /_search
"in_order" : false
}
}
}
--------------------------------------------------
// CONSOLE
The `clauses` element is a list of one or more other span type queries
and the `slop` controls the maximum number of intervening unmatched

View File

@ -6,9 +6,7 @@ query maps to Lucene `SpanNotQuery`. Here is an example:
[source,js]
--------------------------------------------------
GET /_search
{
"query": {
"span_not" : {
"include" : {
"span_term" : { "field1" : "hoya" }
@ -25,9 +23,7 @@ GET /_search
}
}
}
}
--------------------------------------------------
// CONSOLE
The `include` and `exclude` clauses can be any span type query. The
`include` clause is the span query whose matches are filtered, and the

View File

@ -6,9 +6,7 @@ Matches the union of its span clauses. The span or query maps to Lucene
[source,js]
--------------------------------------------------
GET /_search
{
"query": {
"span_or" : {
"clauses" : [
{ "span_term" : { "field" : "value1" } },
@ -17,8 +15,6 @@ GET /_search
]
}
}
}
--------------------------------------------------
// CONSOLE
The `clauses` element is a list of one or more other span type queries.

View File

@ -6,37 +6,25 @@ Matches spans containing a term. The span term query maps to Lucene
[source,js]
--------------------------------------------------
GET /_search
{
"query": {
"span_term" : { "user" : "kimchy" }
}
}
--------------------------------------------------
// CONSOLE
A boost can also be associated with the query:
[source,js]
--------------------------------------------------
GET /_search
{
"query": {
"span_term" : { "user" : { "value" : "kimchy", "boost" : 2.0 } }
}
}
--------------------------------------------------
// CONSOLE
Or :
[source,js]
--------------------------------------------------
GET /_search
{
"query": {
"span_term" : { "user" : { "term" : "kimchy", "boost" : 2.0 } }
}
}
--------------------------------------------------
// CONSOLE

View File

@ -6,9 +6,7 @@ query maps to Lucene `SpanWithinQuery`. Here is an example:
[source,js]
--------------------------------------------------
GET /_search
{
"query": {
"span_within" : {
"little" : {
"span_term" : { "field1" : "foo" }
@ -25,9 +23,7 @@ GET /_search
}
}
}
}
--------------------------------------------------
// CONSOLE
The `big` and `little` clauses can be any span type query. Matching
spans from `little` that are enclosed within `big` are returned.

View File

@ -19,8 +19,8 @@ GET /_search
}
}
}
------------------------------------------
// CONSOLE
The above request is translated into:
@ -34,8 +34,8 @@ GET /_search
}
}
}
------------------------------------------
// CONSOLE
Alternatively passing the template as an escaped string works as well:
@ -53,8 +53,6 @@ GET /_search
}
}
------------------------------------------
// CONSOLE
<1> New line characters (`\n`) should be escaped as `\\n` or removed,
and quotes (`"`) should be escaped as `\\"`.
@ -79,8 +77,6 @@ GET /_search
}
}
------------------------------------------
// CONSOLE
<1> Name of the query template in `config/scripts/`, i.e., `my_template.mustache`.
Alternatively, you can register a query template in the cluster state with:
@ -89,10 +85,9 @@ Alternatively, you can register a query template in the cluster state with:
------------------------------------------
PUT /_search/template/my_template
{
"template": { "match": { "text": "{{query_string}}" }}
"template": { "match": { "text": "{{query_string}}" }},
}
------------------------------------------
// CONSOLE
and refer to it in the `template` query with the `id` parameter:
@ -111,13 +106,9 @@ GET /_search
}
}
------------------------------------------
// CONSOLE
// TEST[continued]
<1> Name of the query template in `config/scripts/`, i.e., `my_template.mustache`.
There is also a dedicated `template` endpoint, allows you to template an entire search request.
Please see <<search-template>> for more details.

View File

@ -6,18 +6,14 @@ Filters documents that have fields that match any of the provided terms
[source,js]
--------------------------------------------------
GET /_search
{
"query": {
"constant_score" : {
"filter" : {
"terms" : { "user" : ["kimchy", "elasticsearch"]}
}
}
}
}
--------------------------------------------------
// CONSOLE
The `terms` query is also aliased with `in` as the filter name for
simpler usage deprecated[5.0.0,use `terms` instead].
@ -67,24 +63,21 @@ possible, reducing the need for networking.
[float]
===== Terms lookup twitter example
At first we index the information for user with id 2, specifically, its
followers, than index a tweet from user with id 1. Finally we search on
all the tweets that match the followers of user 2.
[source,js]
--------------------------------------------------
PUT /users/user/2
{
# index the information for user with id 2, specifically, its followers
curl -XPUT localhost:9200/users/user/2 -d '{
"followers" : ["1", "3"]
}
}'
PUT /tweets/tweet/1
{
# index a tweet, from user with id 1
curl -XPUT localhost:9200/tweets/tweet/1 -d '{
"user" : "1"
}
}'
GET /tweets/_search
{
# search on all the tweets that match the followers of user 2
curl -XGET localhost:9200/tweets/_search -d '{
"query" : {
"terms" : {
"user" : {
@ -95,9 +88,8 @@ GET /tweets/_search
}
}
}
}
}'
--------------------------------------------------
// CONSOLE
The structure of the external terms document can also include array of
inner objects, for example:

View File

@ -5,13 +5,9 @@ Filters documents matching the provided document / mapping type.
[source,js]
--------------------------------------------------
GET /_search
{
"query": {
"type" : {
"value" : "my_type"
}
}
}
--------------------------------------------------
// CONSOLE

View File

@ -11,40 +11,28 @@ query maps to Lucene `WildcardQuery`.
[source,js]
--------------------------------------------------
GET /_search
{
"query": {
"wildcard" : { "user" : "ki*y" }
}
}
--------------------------------------------------
// CONSOLE
A boost can also be associated with the query:
[source,js]
--------------------------------------------------
GET /_search
{
"query": {
"wildcard" : { "user" : { "value" : "ki*y", "boost" : 2.0 } }
}
}
--------------------------------------------------
// CONSOLE
Or :
[source,js]
--------------------------------------------------
GET /_search
{
"query": {
"wildcard" : { "user" : { "wildcard" : "ki*y", "boost" : 2.0 } }
}
}
--------------------------------------------------
// CONSOLE
This multi term query allows to control how it gets rewritten using the
<<query-dsl-multi-term-rewrite,rewrite>>