Skip to content

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

Merged
merged 1 commit into from
Apr 1, 2025

Conversation

ioanatia
Copy link
Contributor

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 the FORK branches when doing the query builder rewrite for FullTextFunction expressions.

The fix is tested through CSV tests that do semantic search in FORK branches.

@ioanatia ioanatia added >non-issue Team:Analytics Meta label for analytical engine team (ESQL/Aggs/Geo) :Search Relevance/Search Catch all for Search Relevance v9.1.0 labels Mar 31, 2025
@ioanatia ioanatia mentioned this pull request Feb 24, 2025
20 tasks
@ioanatia ioanatia marked this pull request as ready for review March 31, 2025 18:13
@ioanatia ioanatia requested a review from ChrisHegarty March 31, 2025 18:14
@elasticsearchmachine elasticsearchmachine added the Team:Search Relevance Meta label for the Search Relevance team in Elasticsearch label Mar 31, 2025
@elasticsearchmachine
Copy link
Collaborator

Pinging @elastic/es-search-relevance (Team:Search Relevance)

@elasticsearchmachine elasticsearchmachine removed the Team:Analytics Meta label for analytical engine team (ESQL/Aggs/Geo) label Mar 31, 2025
Holder<Boolean> hasFullTextFunction = new Holder<>(false);
p.forEachExpression(FullTextFunction.class, unused -> hasFullTextFunction.set(true));

if (p instanceof Fork fork) {
Copy link
Member

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

Copy link
Contributor Author

@ioanatia ioanatia Apr 1, 2025

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.

Copy link
Member

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 -> {
Copy link
Member

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

Copy link
Member

@carlosdelest carlosdelest left a comment

Choose a reason for hiding this comment

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

LGTM

Copy link
Contributor

@ChrisHegarty ChrisHegarty left a comment

Choose a reason for hiding this comment

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

LGTM

@ioanatia ioanatia merged commit fd1c008 into elastic:main Apr 1, 2025
16 of 17 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
>non-issue :Search Relevance/Search Catch all for Search Relevance Team:Search Relevance Meta label for the Search Relevance team in Elasticsearch v9.1.0
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants