2015-05-05 02:27:52 -04:00
|
|
|
[[query-dsl-terms-query]]
|
2015-06-03 19:59:22 -04:00
|
|
|
=== Terms Query
|
2013-08-28 19:24:34 -04:00
|
|
|
|
|
|
|
Filters documents that have fields that match any of the provided terms
|
|
|
|
(*not analyzed*). For example:
|
|
|
|
|
|
|
|
[source,js]
|
|
|
|
--------------------------------------------------
|
2016-05-24 05:58:43 -04:00
|
|
|
GET /_search
|
2013-08-28 19:24:34 -04:00
|
|
|
{
|
2016-05-24 05:58:43 -04:00
|
|
|
"query": {
|
|
|
|
"constant_score" : {
|
|
|
|
"filter" : {
|
|
|
|
"terms" : { "user" : ["kimchy", "elasticsearch"]}
|
|
|
|
}
|
2013-08-28 19:24:34 -04:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
--------------------------------------------------
|
2016-05-24 05:58:43 -04:00
|
|
|
// CONSOLE
|
2013-08-28 19:24:34 -04:00
|
|
|
|
2015-05-05 02:27:52 -04:00
|
|
|
The `terms` query is also aliased with `in` as the filter name for
|
Switch to using ParseField to parse query names
* [TEST] check registered queries one by one in SearchModuleTests
* Switch to using ParseField to parse query names
If we have a deprecated query name, at the moment we don't have a way to log any deprecation warning nor fail when we are in strict mode. With this change we use ParseField, which will take care of the camel casing that we currently do manually (so that one day we can remove it more easily). This also means, that each query will have a unique preferred name, and all the other names are deprecated.
Terms query "in" synonym is now formally deprecated, as well as fuzzy_match, match_fuzzy, match_phrase and match_phrase_prefix for match query, mlt for more_like_this and geo_bbox for geo_bounding_box. All these will be removed in 6.0.
Every QueryParser holds now a ParseField constant called QUERY_NAME_FIELD that holds the name for it. The first name is the preferred one, all the others are deprecated. The first name is taken from the NAME constant already present in each query builder object, so that we somehow keep the serialization constant separated from ParseField. This change also allowed us to remove the names method from the QueryParser interface.
2016-04-05 09:38:53 -04:00
|
|
|
simpler usage deprecated[5.0.0,use `terms` instead].
|
2013-08-28 19:24:34 -04:00
|
|
|
|
|
|
|
[float]
|
2015-06-03 19:59:22 -04:00
|
|
|
[[query-dsl-terms-lookup]]
|
|
|
|
===== Terms lookup mechanism
|
2013-08-28 19:24:34 -04:00
|
|
|
|
|
|
|
When it's needed to specify a `terms` filter with a lot of terms it can
|
|
|
|
be beneficial to fetch those term values from a document in an index. A
|
|
|
|
concrete example would be to filter tweets tweeted by your followers.
|
|
|
|
Potentially the amount of user ids specified in the terms filter can be
|
|
|
|
a lot. In this scenario it makes sense to use the terms filter's terms
|
|
|
|
lookup mechanism.
|
|
|
|
|
|
|
|
The terms lookup mechanism supports the following options:
|
|
|
|
|
|
|
|
[horizontal]
|
2015-06-03 19:59:22 -04:00
|
|
|
`index`::
|
2013-08-28 19:24:34 -04:00
|
|
|
The index to fetch the term values from. Defaults to the
|
|
|
|
current index.
|
|
|
|
|
2015-06-03 19:59:22 -04:00
|
|
|
`type`::
|
2013-08-28 19:24:34 -04:00
|
|
|
The type to fetch the term values from.
|
|
|
|
|
2015-06-03 19:59:22 -04:00
|
|
|
`id`::
|
2013-08-28 19:24:34 -04:00
|
|
|
The id of the document to fetch the term values from.
|
|
|
|
|
2015-06-03 19:59:22 -04:00
|
|
|
`path`::
|
2013-08-28 19:24:34 -04:00
|
|
|
The field specified as path to fetch the actual values for the
|
|
|
|
`terms` filter.
|
|
|
|
|
2015-06-03 19:59:22 -04:00
|
|
|
`routing`::
|
2013-08-28 19:24:34 -04:00
|
|
|
A custom routing value to be used when retrieving the
|
|
|
|
external terms doc.
|
|
|
|
|
|
|
|
The values for the `terms` filter will be fetched from a field in a
|
|
|
|
document with the specified id in the specified type and index.
|
|
|
|
Internally a get request is executed to fetch the values from the
|
|
|
|
specified path. At the moment for this feature to work the `_source`
|
|
|
|
needs to be stored.
|
|
|
|
|
|
|
|
Also, consider using an index with a single shard and fully replicated
|
|
|
|
across all nodes if the "reference" terms data is not large. The lookup
|
|
|
|
terms filter will prefer to execute the get request on a local node if
|
|
|
|
possible, reducing the need for networking.
|
|
|
|
|
|
|
|
[float]
|
2015-06-03 19:59:22 -04:00
|
|
|
===== Terms lookup twitter example
|
2016-05-24 05:58:43 -04:00
|
|
|
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.
|
2013-08-28 19:24:34 -04:00
|
|
|
|
|
|
|
[source,js]
|
|
|
|
--------------------------------------------------
|
2016-05-24 05:58:43 -04:00
|
|
|
PUT /users/user/2
|
|
|
|
{
|
|
|
|
"followers" : ["1", "3"]
|
|
|
|
}
|
2013-08-28 19:24:34 -04:00
|
|
|
|
2016-05-24 05:58:43 -04:00
|
|
|
PUT /tweets/tweet/1
|
|
|
|
{
|
|
|
|
"user" : "1"
|
|
|
|
}
|
2013-08-28 19:24:34 -04:00
|
|
|
|
2016-05-24 05:58:43 -04:00
|
|
|
GET /tweets/_search
|
|
|
|
{
|
|
|
|
"query" : {
|
|
|
|
"terms" : {
|
|
|
|
"user" : {
|
|
|
|
"index" : "users",
|
|
|
|
"type" : "user",
|
|
|
|
"id" : "2",
|
|
|
|
"path" : "followers"
|
|
|
|
}
|
|
|
|
}
|
2013-08-28 19:24:34 -04:00
|
|
|
}
|
2016-05-24 05:58:43 -04:00
|
|
|
}
|
2013-08-28 19:24:34 -04:00
|
|
|
--------------------------------------------------
|
2016-05-24 05:58:43 -04:00
|
|
|
// CONSOLE
|
2013-08-28 19:24:34 -04:00
|
|
|
|
|
|
|
The structure of the external terms document can also include array of
|
|
|
|
inner objects, for example:
|
|
|
|
|
|
|
|
[source,js]
|
|
|
|
--------------------------------------------------
|
|
|
|
curl -XPUT localhost:9200/users/user/2 -d '{
|
|
|
|
"followers" : [
|
|
|
|
{
|
|
|
|
"id" : "1"
|
|
|
|
},
|
|
|
|
{
|
|
|
|
"id" : "2"
|
|
|
|
}
|
|
|
|
]
|
|
|
|
}'
|
|
|
|
--------------------------------------------------
|
|
|
|
|
|
|
|
In which case, the lookup path will be `followers.id`.
|