-
Notifications
You must be signed in to change notification settings - Fork 25.2k
ES|QL: Enable semantic search in FORK #125960
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
Conversation
Pinging @elastic/es-search-relevance (Team:Search Relevance) |
Holder<Boolean> hasFullTextFunction = new Holder<>(false); | ||
p.forEachExpression(FullTextFunction.class, unused -> hasFullTextFunction.set(true)); | ||
|
||
if (p instanceof Fork fork) { |
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.
Should Fork
implement forEachExpression
instead? That would make things easier for the clients that will not need to take it into account, and be in line with the Composite
pattern...
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.
No, Fork
should not implement forEachExpression
.
There is a slippery slope if we decide to do that since in the future we might decide we need to implement anyMatch
, forEachExpressionUp
, forEachExpressionDown
etc and that's not what we want.
We either treat Fork
as the outlier it currently is (because we have nothing like it in ES|QL atm) or we go back and make Fork
a n-ary plan (it is currently a UnaryPlan
).
If Fork
sub plans are treated as children then we would most likely not need to make any big changes to QueryBuilderResolver
.
While it sound good in theory to just make Fork
a n-ary plan, we tried this already when we did the POC and found out it has its own set of challenges.
So for now I am focusing on getting Fork
to work as it should even if it means having this special handling in a couple of places.
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.
If you already went down that route, that's enough to me 😅
@@ -91,5 +108,15 @@ public FullTextFunctionsRewritable rewrite(QueryRewriteContext ctx) throws IOExc | |||
} | |||
return updated.get() ? new FullTextFunctionsRewritable(newPlan) : this; | |||
} | |||
|
|||
private LogicalPlan transformPlan(LogicalPlan plan, Function<FullTextFunction, ? extends Expression> rule) { | |||
return plan.transformExpressionsDown(FullTextFunction.class, rule).transformDown(Fork.class, fork -> { |
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.
Same here, we may override transformExpressionsDown
for Fork
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
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
tracked in #121950
semantic search does not currently work in FORK branches - this was listed as a follow up in #121950
The fix requires modifying the
QueryBuilderResolver
to include theFORK
branches when doing the query builder rewrite forFullTextFunction
expressions.The fix is tested through CSV tests that do semantic search in FORK branches.