[feature request] Parent aggregation

[Kamapcuc]

For example, I have data:

PUT test
PUT test/battle/_mapping
{
  "battle": {
    "_parent": {
      "type": "tank"
    }
  }
}

PUT test/tank/sherman
{"nation" : "usa"}

PUT test/tank/hellcat
{"nation" : "usa"}

PUT test/tank/panter
{"nation" : "germany"}

PUT test/battle/1?parent=sherman
PUT test/battle/2?parent=hellcat
PUT test/battle/3?parent=hellcat
PUT test/battle/4?parent=hellcat
PUT test/battle/5?parent=panter
PUT test/battle/6?parent=panter
{
  "date": "15.02.2015",
  "result": "win"
}

So, I played 4 battles on American tanks and 2 on German tanks. I want to receive those data, when searching for battles. But I can do it only when I search for tanks:

GET test/tank/_search
{
  "size": 0,
  "aggs": {
    "nation": {
      "terms": {
        "field": "nation"
      },
      "aggs": {
        "battles_count": {
          "children": {
            "type": "battle"
          }
        }
      }
    }
  }
}

Although, I can make such a monster:

GET replays/battle/_search
{
  "size": 0,
  "aggs": {
    "usa": {
      "filter": {
        "has_parent": {
          "parent_type": "tank",
          "query": {
            "term": {
              "nation": "usa"
            }
          }
        }
      },
      "aggs": {
        "count": {
          "value_count": {
            "field": "_id"
          }
        }
      }
    },
    "germany": {
      "filter": {
        "has_parent": {
          "parent_type": "tank",
          "query": {
            "term": {
              "nation": "germany"
            }
          }
        }
      },
      "aggs": {
        "count": {
          "value_count": {
            "field": "_id"
          }
        }
      }
    }
  }
}

But it's VERY uncomfortable and I must know all the terms of nation field. So, I'm asking for some kind of parent aggregation.

[Kamapcuc]

Can you please explain what is "high hanging fruit"? I can suggest that mean lowest priority - am i right?

[javanna]

Hi @Kamapcuc good question :) it's not about priority, more about the effort required for the change. Low hanging fruits are easier to get than high hanging ones, that's it. Issues marked with the "high hanging fruit" label might require some refactoring on our end for instance, but that doesn't mean we make all of the easy changes first.

[gmenegatti]

Hi @martijnvg, now that the Parent/Child refactor was committed, do you think we can expect the Parent Aggregation in a near future?

[ppf2]

+1

[Kamapcuc]

is there any progress?

[Kamapcuc]

Ok, i think it's time to start to contribute to the project ))

[clintongormley]

I doubt this is ever going to come to pass. Closing

[DavidHauger]

Would love and need that, too! Maybe with the new ways of joining in elastic 6?

[centic9]

Yeah, I miss this a lot as well, prevents us from switching from nested to parent/child for one of our large use-cases...

[centic9]

I tried to implement the parent-aggregation and would like some feedback if the approach is correct, see #34210

[jimczi]

Oups I reopened the issue by mistake. https://github.com/elastic/elasticsearch/pull/34210 has been merged so we'll have support for parent aggregation starting in version 6.6. Thanks again @centic9 !

[Kamapcuc]

Yeah, thanks you @centic9 ! :)