Skip to content
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

Merged
merged 9 commits into from
Oct 25, 2023

Conversation

nik9000
Copy link
Member

@nik9000 nik9000 commented Oct 9, 2023

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.

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`.
@elasticsearchmachine elasticsearchmachine added the Team:QL (Deprecated) Meta label for query languages team label Oct 9, 2023
@elasticsearchmachine
Copy link
Collaborator

Pinging @elastic/es-ql (Team:QL)

@elasticsearchmachine
Copy link
Collaborator

Pinging @elastic/elasticsearch-esql (:Query Languages/ES|QL)

@nik9000
Copy link
Member Author

nik9000 commented Oct 9, 2023

This is almost 100% mechanical. I sort of did it out of anger to remove a weird toString. But I do think it's nicer.

@nik9000
Copy link
Member Author

nik9000 commented Oct 9, 2023

run elasticsearch-ci/part-1

Copy link
Contributor

@bpintea bpintea left a 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 {
Copy link
Contributor

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.)

Copy link
Member Author

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.

Copy link
Member Author

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 + "]";
Copy link
Contributor

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[..."?

Copy link
Member Author

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(
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍🏻

Copy link
Contributor

@alex-spies alex-spies left a 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).

@@ -99,15 +104,22 @@ private TypeSpec type() {
return builder.build();
}

private MethodSpec ctor() {
private MethodSpec ctor(Implementing implementing) {
Copy link
Contributor

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.

Copy link
Member Author

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) {
Copy link
Contributor

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.

@nik9000
Copy link
Member Author

nik9000 commented Oct 25, 2023

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.

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.....

@nik9000 nik9000 added the auto-merge-without-approval Automatically merge pull request when CI checks pass (NB doesn't wait for reviews!) label Oct 25, 2023
@elasticsearchmachine elasticsearchmachine merged commit 9796de4 into elastic:main Oct 25, 2023
12 checks passed
@nik9000 nik9000 deleted the esql_gen_tostring_think branch October 25, 2023 17:57
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
:Analytics/ES|QL AKA ESQL auto-merge-without-approval Automatically merge pull request when CI checks pass (NB doesn't wait for reviews!) >non-issue Team:QL (Deprecated) Meta label for query languages team v8.12.0
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants