has-child-query.asciidoc 1.9 KB

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