Match parent docs & root in nested query

[rainbow-alex]

In my app I am building complex queries on documents containing nested documents. The queries are built on the fly from user input combined with configurable authorization rules. (Needless to say the queries get quite complex.) I am running into trouble when I need to logically combine (using and/or/not) queries on the root document with queries on a single nested document.

In its simplest form:

{root query 1 OR nested query 1} AND {root query 2 OR nested query 2}

Where nested query 1 & 2 should pertain to the same nested document. This is only possible if the nested queries are written as a single nested query, with the boolean combinator inside; but then the root queries have no fields to match...

@markharwood suggested rewriting the query but I am not sure that is logically possible in all cases. In any case it is very inconvenient whether you are writing queries by hand or building them some other way.

Is it possible to provide a 'reverse_nested' query that goes back to a parent document/root context? Logically this query would return to a parent context to evaluate the given filter.

P.S. My current workaround is copying the required root fields to each nested document -- :(

[clintongormley]

P.S. My current workaround is copying the required root fields to each nested document -- :(

This is probably a better solution which will perform better at query time.

@martijnvg would this even be possible?

[rainbow-alex]

This is probably a better solution which will perform better at query time.

I feared as much. Logically when you return to parent/root context you only need to consider one document that is already 'on hand'; but that thinking probably doesn't match the internals.

Alternatively; if it is possible to (automatically) rewrite the queries so that all the 'reverse_nested' queries are lifted out the query planner could do so and it might perform ok?

[andyb-elastic]

From the discussion here and the lack of activity it looks like this isn't something we currently want to implement, so I'm going to close this issue. Additional feedback is always welcome and we'll reconsider if there's interest from the community

[DavidHauger]

There are quite a couple of use cases for this. We would really need that and hoped that elastic 6 would bring improvements... Waiting for something like this since 2.0 - let's hope it will be put on the roadmap for 7.x. Many features are nice to have, but you can still implement things on your own; but functionality that is missing on low level is a real pain. With several thousand TB of elastic storage, de-normalization and a 10-50 times higher storage (+ implied load on index writes, queries, etc) is not really an option...

[extJo]

@andyb-elastic any plan for support this issue?