|
|
@@ -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.
|
|
|
|
Adam Menges