-
Notifications
You must be signed in to change notification settings - Fork 24.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[ML] Add lazy parsing for DatafeedConfig:Aggs,Query #36117
[ML] Add lazy parsing for DatafeedConfig:Aggs,Query #36117
Conversation
Pinging @elastic/ml-core |
x-pack/plugin/core/src/main/java/org/elasticsearch/xpack/core/ml/datafeed/DatafeedConfig.java
Outdated
Show resolved
Hide resolved
x-pack/plugin/core/src/main/java/org/elasticsearch/xpack/core/ml/datafeed/DatafeedConfig.java
Outdated
Show resolved
Hide resolved
I'd definitely like to see this in 6.7, because then a mixed version cluster of 7.x and 6.last is guaranteed not to fail due to search or aggs syntax that's been removed in 7.0. I don't think it would hurt to introduce this into 6.x while it's still 6.6. Since this work is nearly complete I think we should do this, then merge master and 6.x into the corresponding jindex branches and make sure it works in those branches too before merging them to master and 6.x. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
* Lazily parsing aggs and query in DatafeedConfigs * Adding parser tests * Fixing exception types && unneccessary checked ex * Adding semi aggregation parser * Adding tests, fixing up semi-parser * Reverting semi-parsing * Moving agg validations * Making bad configs throw badRequestException
This adds lazy parsing for DatafeedConfig Aggregations and Queries.
When creating a NEW Datafeed, the STRICT parser is used, which eagerly parses both to catch any formatting errors.
When an already stored config is read in, the LENIENT parser is used and simply pulls in the aggs and datafeed as maps. When serializing on the wire or to XContent, the maps are used directly. However, if the in/out streams are of an earlier version, they are fully parsed before sending over the wire.
Right now the BWC checks are for
Version.CURRENT
as I am not sure if we want to put this in 6.x. Let me know what you think.When a lazy parsing issue occurs, I am currently throwing a
UNPROCESSABLE_ENTITY
REST error. However, the argument could be made that they should just beIllegalArgument
exceptions or aXContentParseException
, need feedback :).