Issue 1:
ES 1.4 added support for Children aggregation, which is a really great feature.

The next step would be to also support a Parent aggregation

Here is a quick example of a typical use case:

Let's say we've got 2 types, one containing Product information (name, description, categories, size, weight, etc) and another one containing Reseller information (location, price, etc..).

There is a parent child relationship between Products and Resellers (Product being the parent)

In some cases, one may want to aggregate on Parent property.

GET parentchild/reseller/_search/
{
"query": {
... // not relevant here
},
"sort": [
{
"price": {
"order": "asc",
"mode": "avg"
}
}
],
"aggs": {
"location": {
"geo_distance": {
"unit": "km",
"field": "location",
"origin": "lat, lon",
"ranges": [
{ "from": 0, "to": 100},
....
]
}
},
"price": {
"range": {
"field": "price",
"ranges": [
{ "from": 0, "to": 50},
...
]
}
},
"aggregateOnParent": {
"parent": {},
"aggs": {
"category": {
"term": {
"field": "category" // Note that category is a field of Product (the parent)
}
}
}
}
}
}
}

Issue 2:
I understand that issue #9611 was closed regarding this:

Nested fields need to be queries with nested queries/filters, because multiple documents can match and you need to be able to specify how these multiple scores should be reduced to a single score.

— -- @clintongormley

Proposal

I propose that, when a field name within a query string query is parsed, and it does not match a field mapping, an attempt should be made to match the field name to a nested object mapper. If the attempt is successful, the query text for that field name should then be parsed as a query string query using the same settings as the root level query string query. The resulting query from that parsing will in turn be used to create a ToParentBlockJoinQuery (a nested query) that uses the same default scoring mode that would be applied when manually submitting a nested query ("avg".)

The syntax

The acceptable syntax for a nested query within a query string query is similar to this:

nestedPath:"<query string query>"

This means that any constructs you would use in a query string query are valid:

children:"children.first:peggy"

children:"children.first:\"peggy\""

children:"children.first:(peggy ruby)"

children:"children.first:peggy AND children.last:sue"

children:"children.first:pegyg~ +children.last:su?"

Note that the nested query MUST be surrounded with quotes. I wanted it to be parentheses instead but unfortunately the Lucene QueryParser class does not recognize the field names the way I wanted it to (children:(children.first:peggy) would come out as a TermQuery on children.first, the children field name would be discarded.)

Other considerations

Support for specifying scoring modes within the query string query settings based on nested object paths is a possibility.

Support for inner hits may also be a possibility, in a similar fashion to scoring modes.

Support for nested queries in query strings at all would be an enhancement, but these options could provide additional enhancements. Example of how they may look:

{
"query_string" : {
"query" : "children:\"children.first:peggy\"",
"nested": [
{
"path": "children",
"score_mode": "max",
"inner_hits": {
<inner_hits_options>
}
}
]
}
}

Pull request

For the basic functionality, I have already made the necessary modifications (three changed files, one changed test file to add a test with several assertions) on the 'master' branch of my local clone of the repository. I would like to submit a pull request; please advise as to how you would like that to be done (if I need to rebase onto another branch, etc.)