1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
|
[[query-dsl-has-child-query]]
=== Has Child Query
The `has_child` query works the same as the
<<query-dsl-has-child-filter,has_child>> filter,
by automatically wrapping the filter with a
<<query-dsl-constant-score-query,constant_score>>
(when using the default score type). It has the same syntax as the
<<query-dsl-has-child-filter,has_child>> filter:
[source,js]
--------------------------------------------------
{
"has_child" : {
"type" : "blog_tag",
"query" : {
"term" : {
"tag" : "something"
}
}
}
}
--------------------------------------------------
An important difference with the `top_children` query is that this query
is always executed in two iterations whereas the `top_children` query
can be executed in one or more iteration. When using the `has_child`
query the `total_hits` is always correct.
[float]
==== Scoring capabilities
The `has_child` also has scoring support. The
supported score types are `max`, `sum`, `avg` or `none`. The default is
`none` and yields the same behaviour as in previous versions. If the
score type is set to another value than `none`, the scores of all the
matching child documents are aggregated into the associated parent
documents. The score type can be specified with the `score_type` field
inside the `has_child` query:
[source,js]
--------------------------------------------------
{
"has_child" : {
"type" : "blog_tag",
"score_type" : "sum",
"query" : {
"term" : {
"tag" : "something"
}
}
}
}
--------------------------------------------------
[float]
==== Memory Considerations
With the current implementation, all `_id` values are loaded to memory
(heap) in order to support fast lookups, so make sure there is enough
memory for it.
|
