-
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
ESQL: Generate evaluator factories #100516
ESQL: Generate evaluator factories #100516
Conversation
This generates the evaluator factories which we'd been implementing inline with `->`. The advantage of generating them is that they have a useful `toString` and class name. These are useful for debugging and let us remove a kind of errant use `ThrowingDriverContext` just to generate a factory description for logging. Now we can just use the generated `toString`.
Pinging @elastic/es-ql (Team:QL) |
Pinging @elastic/elasticsearch-esql (:Query Languages/ES|QL) |
This is almost 100% mechanical. I sort of did it out of anger to remove a weird |
run elasticsearch-ci/part-1 |
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.
I first thought that the change is rather large just for factory's toString()
, but then not having to inline these factories seems quite comfy too, so it LGTM.
@@ -156,11 +143,40 @@ public static BatchEncoder batchEncoder(Block.Ref ref, int batchSize, boolean al | |||
} | |||
} | |||
|
|||
private abstract static class MvDedupeEvaluator implements EvalOperator.ExpressionEvaluator { | |||
protected final EvalOperator.ExpressionEvaluator field; | |||
private static class EvaluatorFactory implements ExpressionEvaluator.Factory { |
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.
Could this and the Evaluator
below not be a record, to make these more concise?
(And same for the evaluator implementers.)
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.
I can do that here. The other ones I'm kind of stuck on because javapoet can't make records. Or, at least, it couldn't when I last checked.
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.
square/javapoet#981 for reference.
|
||
@Override | ||
public String toString() { | ||
return "MvDedupe[field=" + field + "]"; |
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.
Wouldn't we want to distinguish the factory from the produced object itself? I.e. should this be a "MvDedupeFactory[..."?
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.
Previously we were didn't use that in the toString and I think that's pretty ok here because it end up some of the debug information.
return dvrCtx -> buildEvaluator.apply(lhs.get(dvrCtx), rhs.get(dvrCtx), dvrCtx); | ||
} | ||
|
||
public static ExpressionEvaluator.Factory castToEvaluatorWithSource( |
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.
👍🏻
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.
Didn't look at all files since most changes are mechanical.
LGTM except that I find the EvaluatorImplementer
a bit confusing to read since we emit code for either the factory or the outer class based on a switch that's applied to nearly every function - IMHO separating into two sets of functions would be easier to follow since the code already comes with a lot of indirections (since it generates code).
x-pack/plugin/esql/compute/ann/src/main/java/org/elasticsearch/compute/ann/Fixed.java
Outdated
Show resolved
Hide resolved
@@ -99,15 +104,22 @@ private TypeSpec type() { | |||
return builder.build(); | |||
} | |||
|
|||
private MethodSpec ctor() { | |||
private MethodSpec ctor(Implementing implementing) { |
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.
suggestion: I found this confusing to read; I think it would be simpler to just have a private MethodSpec ctor()
and a private MethodSpec factoryCtor()
.
The code duplication is probably negligible - and I think it's fair to have 2 different methods, given that we also emit 2 methods that are not inherently related.
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.
Checking!
@@ -439,16 +512,28 @@ public String paramName(boolean blockStyle) { | |||
} | |||
|
|||
@Override | |||
public void declareField(TypeSpec.Builder builder) { | |||
builder.addField(ArrayTypeName.of(EXPRESSION_EVALUATOR), name, Modifier.PRIVATE, Modifier.FINAL); | |||
public void declareField(Implementing implementing, TypeSpec.Builder builder) { |
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.
Similarly here, I think we might as well replace the implementing
argument by an array type name - this would make code that call declareField
easier to understand.
Maybe it'd be better to get rid of the Implementing
enum.
It really is too big! It's kind of a sign that generating all this code ain't great. Or, at least, committing the generated code..... |
…/compute/ann/Fixed.java Co-authored-by: Alexander Spies <[email protected]>
…think' into esql_gen_tostring_think
This generates the evaluator factories which we'd been implementing inline with
->
. The advantage of generating them is that they have a usefultoString
and class name. These are useful for debugging and let us remove a kind of errant useThrowingDriverContext
just to generate a factory description for logging. Now we can just use the generatedtoString
.