-
Notifications
You must be signed in to change notification settings - Fork 24.5k
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
[ESQL] Dependency Injection for the Warnings Collector #108635
Conversation
@elasticmachine update branch |
@elasticmachine update branch |
@elasticmachine update branch |
Pinging @elastic/es-analytical-engine (Team:Analytics) |
Had a chat with Mark about the logistics behind it - to avoid the noise of having every
To address the original bug, this logic would be expanded to contain a tryFold() method would not throw warnings OR revisit the folding semantics so that folding does NOT throw warnings (since it can only occur on literals). |
Closing in favor of #108927. With the requested changes and the large number of conflicts due to the big refactor, it was faster to just start from scratch. |
This lays the groundwork for fixing #108519, although I don't intend to fix it in this PR. In order to address that issue, we need to be able to control at call time how we deal with warnings, but, prior to this work, the ExpressionEvaluators all hard code their warnings implementation. This PR will allow injecting in a different implementation when we create the evaluator. Unfortunately, this has fallen slightly short of that ambition. We need to be able to construct evaluators from within compute, but the Warnings class, and it's Source dependency, are in the esql package, which we don't want to import into compute. As result, I've pared this back to just passing in a toggle for warnings collection, via a no-op collector implementation. This is sufficient to solve the linked issue (still not done in this PR) and preserves our current encapsulation, while leaving a clear path to further refine how we control warnings in the future. Note that this is changing the code generation, which means it will touch all of the generated files, which are still in source control. The actual change is much smaller than the diff would imply. Replaces #108635
This lays the groundwork for fixing #108519, although I don't intend to fix it in this PR. In order to address that issue, we need to be able to control at call time how we deal with warnings, but, prior to this work, the
ExpressionEvaluators
all hard code their warnings implementation.This PR will allow injecting in a different implementation when we create the evaluator.Unfortunately, this has fallen slightly short of that ambition. We need to be able to construct evaluators from within compute, but theWarnings
class, and it'sSource
dependency, are in the esql package, which we don't want to import into compute. As result, I've pared this back to just passing in a boolean to toggle warnings collection, via a no-op collector implementation. This is sufficient to solve the linked issue (still not done in this PR) and preserves our current encapsulation, while leaving a clear path to further refine how we control warnings in the future.Note that this is changing the code generation, which means it will touch all of the generated files, which are still in source control. The actual change is much smaller than the diff would imply.