Percolator not working with referenced parent/child queries

[randunel]

I have a parent and a child collection. The child has the parent properly declared, and all the _search queries seem to be working correctly. But the percolator doesn't seem to work with the has_child query. Is this feature implemented?

[imotov]

Because the percolator API is processing one document at a time, it doesn’t support queries and filters that run against child and nested documents such as has_child, has_parent, top_children, and nested.

[javanna]

Nested documents support was added to the percolator in #5082.

Parent/child is still not supported but we might be able to support it in the future, reopening this issue in the meantime.

[rore]

+1, we have a strong need for this.

[razafinr]

Any information about Parent/Child document support in future version ? Having an application based on this kind of relations and I am stuck while using percolator

[mgreene]

We would have a need for this also. Currently we've had to refactor our child documents into nested fields inside the parent doc. The trade off here is that our parent docs are being reindexed faster than they other would. Doesn't dramatically impact our deployment but would prefer to leverage child documents for their strengths in conjunction with percolators.

[clintongormley]

@martijnvg do you think it is feasible that we could support parent/child in the percolator in the future? Or is it just a no go?

[mgreene]

Actually after thinking about this for a while, support for parent/child in the percolator doesn't make a ton of sense, at least for our use case.

One of the main reasons to use child documents in the first place is that you anticipate a lot of writes and don't want to trigger a parent doc reindex every time.

We have decently high cardinality (high hundreds in some cases) with our child documents so paging every single one of those into memory to throw against the percolator would prove to be prohibitive as the data set continues to grow. I suspect this was one of the reasons why it was not supported in the first place.

[clintongormley]

@mgreene That's my thinking too, but I'll leave this here in case @mvg has some cleverer way of implementing this.

[martijnvg]

@mgreene @clintongormley I think ES can support parent/child queries in the percolator, but it is odd to do this for the reasons @mgreene mentioned. (store the documents in memory and toss it away and perform the next percolator request).

What I think would be a nice addition to the percolator is to support percolating multiple documents in a single percolator call. So instead of defining a single doc element, the percolator should then support a docs element which would allow an array of documents. Regardless if parent/child should be supported this on its own can be a good addition.

[jpountz]

I suggest that we document that the percolator does not support parent/child queries and close this.

[martijnvg]

The fact that these queries can't be used is already documented: https://github.com/elastic/elasticsearch/blob/master/docs/reference/mapping/types/percolator.asciidoc#limitations

In order to make it more clear that these queries are not supported, I also suggest that fail adding a percolator query that contains a has_child or has_parent query in the same as we fail when a percolator query contains range query with range based on the current time (now).

[jpountz]

+1

[jpountz]

Thanks @martijnvg !