parent
24f8807cb5
commit
3a3030e217
|
@ -1,14 +1,14 @@
|
|||
[[search-request-inner-hits]]
|
||||
=== Inner hits
|
||||
|
||||
The <<mapping-parent-field, parent/child>> and <<mapping-nested-type, nested>> features allow to return documents that
|
||||
have matches in a different scope. In the parent/child case parent document are returned based on matches in child
|
||||
documents or child document are returned based on matches in parent documents. In the nested case documents are returned
|
||||
The <<mapping-parent-field, parent/child>> and <<mapping-nested-type, nested>> features allow the return of documents that
|
||||
have matches in a different scope. In the parent/child case, parent document are returned based on matches in child
|
||||
documents or child document are returned based on matches in parent documents. In the nested case, documents are returned
|
||||
based on matches in nested inner objects.
|
||||
|
||||
In both cases the actual matches in the different scopes that caused a document to be returned is hidden. In many cases
|
||||
it is very useful to know which inner nested objects in the case of nested or children or parent documents in the case
|
||||
of parent/child caused certain information to be returned. The inner hits feature can be used for this. This feature
|
||||
In both cases, the actual matches in the different scopes that caused a document to be returned is hidden. In many cases,
|
||||
it's very useful to know which inner nested objects (in the case of nested or children or parent documents), or (in the case
|
||||
of parent/child) caused certain information to be returned. The inner hits feature can be used for this. This feature
|
||||
returns per search hit in the search response additional nested hits that caused a search hit to match in a different scope.
|
||||
|
||||
The following snippet explains the basic structure of inner hits:
|
||||
|
@ -36,7 +36,7 @@ is parent/child based.
|
|||
Multiple inner hit definitions can be defined in a single request. In the `<inner_hits_body>` any option for features
|
||||
that `inner_hits` support can be defined. Optionally another `inner_hits` definition can be defined in the `<inner_hits_body>`.
|
||||
|
||||
If `inner_hits` is defined each search will contain a `inner_hits` json object with the following structure:
|
||||
If `inner_hits` is defined, each search will contain a `inner_hits` json object with the following structure:
|
||||
|
||||
[source,js]
|
||||
--------------------------------------------------
|
||||
|
@ -125,7 +125,7 @@ The example below assumes that there is a nested object field defined with the n
|
|||
<1> The inner hit definition is nested and requires the `path` option.
|
||||
<2> The path option refers to the nested object field `comments`
|
||||
|
||||
In the above the query is repeated in both the query and the `comment` inner hit definition. At the moment there is
|
||||
Above, the query is repeated in both the query and the `comment` inner hit definition. At the moment there is
|
||||
no query referencing support, so in order to make sure that only inner nested objects are returned that contributed to
|
||||
the matching of the regular hits, the inner query in the `nested` query needs to also be defined on the inner hits definition.
|
||||
|
||||
|
|
Loading…
Reference in New Issue