@bk thanks.
I'll soon review it.

@bk - thanks.
This will produce the correct result set, but not in the way intended (it will fallback to a query rather than filtering on an 'all' query).

You are losing the performance advantage of filtered queries the method 'all' is meant for through using 'query' as 'match_all => {}' and adding a 'filter' part.
Instead, your solution is changing the 'query' part (without building a 'filter') with the restrictions in it (so ES won't cache your query's results)

In case you wish to correct this, I will be glad to assist if you have any questions.

cheers,
Mickey

@mickeyn - sorry for the late reply. Yes, I would like to improve this according to your wishes.

If I understand you correctly, the aim is to support the same kind of simple syntax as for the more specific methods (i.e. module(), distribution() etc.), but to transform it into an efficient ES filter before it reaches the backend.

Since all() delegates how to handle the query to the more specific methods (which ultimately call ssearch() in most cases), this must mean that these methods (or probably simply the _build_body() method in the Request submodule) could be made more efficient as well. Would you like me to look into that?

By the way, do you have any benchmark data for typical queries so I have some point of reference for what should be considered fast, slow - and "fast enough"?

@bk yes this is the idea (building a filter, using the body builder logic)

closing as this is doesn't seem to be happening.