`min_children` does not play nice with boolean queries

[marshall007]

I believe the expected behavior when has_child is within a must expression is that when zero children are returned, the expression evaluates as "falsey", which makes sense. However, if you set min_children: 0 intuitively I would expect this expression to now evaluate as "truthy" regardless of the number of returned results.

In our case, it makes a lot more sense for us to dynamically adjust the min_children parameter rather than dynamically changing the entire boolean query expression.

Here's an example query demonstrating the issue. We're attempting to find a parent or child document by ID and return both the parent and child. The query fails to match when we find a parent with no children despite min_children: 0:

{
  "size": 1,
  "query": {
    "bool": {
      "should": {
        "terms": {
          "_id": [ "9b6ca518-39be-48e8-b885-bee6fd7ea207" ]
        }
      },
      "must": {
        "has_child": {
          "type": "lab_tests",
          "min_children": 0,
          "query": {
            "bool": {
              "should": [
                {
                  "terms": {
                    "_id": [ "9b6ca518-39be-48e8-b885-bee6fd7ea207" ]
                  }
                },
                {
                  "terms": {
                    "_parent": [ "9b6ca518-39be-48e8-b885-bee6fd7ea207" ]
                  }
                },
                {
                  "terms": {
                    "status": [ "active", "deprecated" ]
                  }
                }
              ],
              "minimum_should_match": 1
            }
          }
        }
      }
    }
  }
}

[clintongormley]

min_children: 0 makes no sense because you are essentially saying match all parents. If you want to find parents with no children, then wrap a has_child query inside of a bool.must_not clause

[marshall007]

@clintongormley the point I'm trying to make here is that not supporting min_children: 0 makes doing a SQL-like "left join" a lot more difficult than it needs to be. In this case we are trying to match all parents even if they don't have any children, not just parents that have no children.

Can you elaborate on why this use-case "makes no sense"? In my mind it's counter-intuitive that this does not work out of the box.

[clintongormley]

I say it makes no sense because it is very ambiguous. Do you intend to match only parents that either have children matching the specified constraints or no have no children at all. You specify min_should_match: 1, so what about parents that have no children which match the constraints. Should those be included or not? In which case surely you just want a match_all on the parents?

I think you mean to exclude parents that have children but those children don't match the constraints. In that case, you can write it as a bool query:

 bool: {
    should: [
       { parents with matching children },
       { parents with no children }
   ]
}

So you can do what you want, but in a way that is much less ambiguous than accepting min_children: 0

[marshall007]

Do you intend to match only parents that either have children matching the specified constraints or no have no children at all.

Given that the parameter name is min children, I don't see how this is an ambiguous statement at all. It's simply "zero or more children matching this query". In other words "return all parents, including any of their children that match this query".

I think you mean to exclude parents that have children but those children don't match the constraints.

This is not quite accurate. We do in fact want to include parents even if their children don't match the constraints, not just parents with zero children.

We currently workaround this by putting both the parent terms query and the has_child in a should clause, but I argue this is far more convoluted than a simple min_children: 0. Especially when you consider that we want to dynamically change this parameter (either 0 or 1). Instead of changing a single param, we're required to restructure the bool query into a must or should depending on whether we want to include parents with no matching children or not.

Furthermore, the fact that min_children: 0 is considered valid, yet behaves more like min_children: 1 is certainly confusing. I think we can at least agree that 0 should not be considered a valid value for this param if it doesn't behave as such.

[clintongormley]

This is not quite accurate. We do in fact want to include parents even if their children don't match the constraints, not just parents with zero children.

OK, that wasn't what i was expecting. So you're using inner hits to return the children? And the children aren't involved in scoring the parent hits? In this case, running a has_child query just to return any matching children for the top 10 results would be an inefficient way of doing it.

I'd rather just get back the top 10 parents, then retrieve any children for those parents in a separate request.

I think we can at least agree that 0 should not be considered a valid value for this param if it doesn't behave as such.

Agreed

[nimelord]

I totally agree with marshall007.
Right now, I have no solution for list all parents with children (including zero number of children), which matched by 'bool section' and must be sorted by custom score.
Improve it please. :)

[cbuescher]

/cc @elastic/es-search-aggs