Implicit nested predicates


At the moment the only way to define a predicate targeting a nested field is using a NestedPredicateFieldStep.
Hence we need to wrap the predicate on the target field with a:

for each nested object we reach traversing the very targeting path.

We could instead allowing users to define such a query without worrying about the fact that a field may or may not be contained in a nested object. As we already do for nested sort and nested projection.

This is particularly important for the sub-case of the exists predicate which is targeting an object field.

in this case we should automatically add a join query ("nested" predicate), in order to match not just the fields within the target object, but also the fields contained in the nested objects that are contained in turn in the target object.

Probably to handle such a query we will need a boolean query grouping all the cases in Elasticsearch as well.

We won't remove the nested API, leaving to the user the chance to use the old/explicit syntax.
Because the explicit syntax could be useful for supporting advanced stuff, such as local filtering on child/parent join and so on and so forth...




Waldemar Kłaczyński
March 13, 2020, 8:36 AM

Elasticsearch wraps the query thus detected in the ESToParentBlockJoinQuery object. A nested query is not always recommended. Because for sorting and agrgregation you need to recover the original form of the query.

Yoann Rodière
March 13, 2020, 11:48 AM

Yes, but explicit filters passed to sorts and aggregations are another problem. Since we now in which context these filters must be executed, we should be able to not apply the "join query" in this case.

Waldemar Kłaczyński
March 13, 2020, 12:48 PM

Filtering queries cannot have BlockJoinQuery. It would be great if they were wrapped up in a class like Elasticsearch. In elastic search is ESToParentBlockJoinQuery. You can always delete and extract the original query, but not to remove other nested query elements. You can even rebuild the wrap, automatically adding or removing nesting elements. Depending on the need.

The function compiles the query in one place, it would also work for LuceneSearchPredicateFactory.fromLuceneQuery. Recompiles so deeply until it encounters ESToParentBlockJoinQuery. In order not to repeat actions from previous predicates.

Recompilation only removes ESToParentBlockJoinQuery and ToParentBlockJoinQuery associated with the path.


Fabio Massimo Ercoli


Fabio Massimo Ercoli



Suitable for new contributors


Feedback Requested


Fix versions

Affects versions