You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Today we have a massive infrastructure to parse all our requests. We have client side builders and server side parsers but no real representation of the query, filter, aggregation etc until it's executed. What is produced from a XContent binary is a Lucene query directly which causes huge parse methods in separate classes etc. that hare hard to test and don't allow decoupled modifications or actions on the query itself between parsing and executing.
This refactoring splits the parsing and the creation of the lucene query, this has a couple of advantages
XContent parsing creation are in one file and can be tested more easily
the class allows a typed in-memory representation of the query that can be modified before a lucene query is build
the query can be normalized and serialized via Streamable to be used as a normalized cache key (not depending on the order of the keys in the XContent)
for the query cache a query tree can be "walked" to rewrite range queries into match all queries with MIN/MAX terms to get cache hits for sliding windows --> Kibana 4 unable to utilize query cache #9526
code wise two classes are merged into one which is nice
The above apis don't necessarily have to change to parse queries in our intermediate format, for instance the percolator will still need to parse to lucene query straight-away, but we should still have a look at each of those and double check if anything needs to be adjusted after all the infra changes we have made.
Copied from #9901:
Today we have a massive infrastructure to parse all our requests. We have client side builders and server side parsers but no real representation of the query, filter, aggregation etc until it's executed. What is produced from a XContent binary is a Lucene query directly which causes huge parse methods in separate classes etc. that hare hard to test and don't allow decoupled modifications or actions on the query itself between parsing and executing.
This refactoring splits the parsing and the creation of the lucene query, this has a couple of advantages
Queries (Completed)
Total of 54 Queries
54 done
Former filters were mostly merged or converted to queries and are included in this list.
Aggregations (Completed - #14136)
Total of 44 Aggregations
44 done
Suggesters
Total of 4 Suggesters
4 done, 0 in open PRs
Highlighters
Total of 3 Highlighters
3 done
Others
query_binary: (removed, queries should only be specified via type-safe builders in the Java API, see Remove query_binary, filter_binary & aggs_binary #14308)filter_binary: (removed, filters should only be specified via type-safe builders in the Java API, see Remove query_binary, filter_binary & aggs_binary #14308)aggregations_binary: (to be removed, aggregations should only be specified via type-safe builders in the Java API, see Remove query_binary, filter_binary & aggs_binary #14308 and Refactoring of Aggregations #14136)APIs to be adapted/revised besides _search
search exists api(removed, see Remove search exists api #13911)index warmers(removed, see Remove query warmers and the warmer API. #15614)The above apis don't necessarily have to change to parse queries in our intermediate format, for instance the percolator will still need to parse to lucene query straight-away, but we should still have a look at each of those and double check if anything needs to be adjusted after all the infra changes we have made.