- Notifications
You must be signed in to change notification settings - Fork 25.6k
Add sub_searches to the search endpoint #96224
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
execute multiple queries individually
| } else { | ||
| throw new XContentParseException( | ||
| parser.getTokenLocation(), | ||
| "malformed query within the [queries] field; found " + token |
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.
Needs a rename
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.
Fixed.
| } else if (rankQueryBuilders.isEmpty() == false) { | ||
| throw new IllegalArgumentException("cannot serialize [rank] to version [" + out.getTransportVersion() + "]"); |
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.
did you mean to delete this?
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.
Yes. This logic was moved to SearchSourceBuilder instead since where that's where subSearchBuilders lives.
Edit: I take that back, that was a different serialization error. I need to think about this.
Second edit: This is correct. We won't serialize multiple searches to anything prior to 8.8 now which is the equivalent to this with the new data structure for sub searches.
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 left a bunch of new comments, mostly cosmetic things, or around hardening certain details. No blockers though, those could also be addressed as a follow-up especially if they require significant effort.
LGTM!
| public SearchSourceBuilder query(QueryBuilder query) { | ||
| this.queryBuilder = query; | ||
| public SearchSourceBuilder query(QueryBuilder queryBuilder) { | ||
| subSearchSourceBuilders = new ArrayList<>(); |
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.
this will reset the list no matter what was previously set to it? What happens if we assert that the list is empty?
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 admit this is a bit fragile, but I think this should be addressed as a follow up. The prior behavior would replace the previous query so asserting there would break updates to this method.
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 see, maybe just assert that there is a single element in the list then so it's 1:1 with the previous behaviour of replacing?
| * Sets the queries for this request. | ||
| */ | ||
| public SearchSourceBuilder subSearches(List<SubSearchSourceBuilder> subSearchSourceBuilders) { | ||
| this.subSearchSourceBuilders = subSearchSourceBuilders; |
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 we enforce that the list can never be null?
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.
Yes! Good call.
server/src/main/java/org/elasticsearch/search/internal/ShardSearchRequest.java Outdated Show resolved Hide resolved
server/src/main/java/org/elasticsearch/search/internal/ShardSearchRequest.java Outdated Show resolved Hide resolved
| // null query means match_all | ||
| canMatch = aliasFilterCanMatch; | ||
| canMatch &= request.source() | ||
| .subSearches() |
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.
will subsearches here already contain the knn queries too? I think so, and that should not be an issue, but I wanted to double check.
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 should never be a knn search here because can_match only works with query_then_fetch, but not dfs_query_Then_fetch.
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.
oh good point. maybe that is something that we need to discuss changing.
server/src/main/java/org/elasticsearch/search/SearchService.java Outdated Show resolved Hide resolved
| if (in.getTransportVersion().onOrAfter(TransportVersion.V_8_8_0) && in.getTransportVersion().before(TransportVersion.V_8_500_004)) { | ||
| List<QueryBuilder> rankQueryBuilders = in.readNamedWriteableList(QueryBuilder.class); | ||
| for (QueryBuilder queryBuilder : rankQueryBuilders) { | ||
| source.queries().add(new SearchQueryWrapperBuilder(queryBuilder)); |
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.
ok so that means that we don't need to add specific tests and we can rely on existing test coverage? Which test specifically are you referring to?
| body: | ||
| track_total_hits: true | ||
| fields: [ "text" ] | ||
| queries: [ |
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.
Hear hear, Jack came up with an improved name, as promised back when we decided to add a new top level element :)
| Hi @jdconrad, I've updated the changelog YAML for you. Note that since this PR is labelled |
sub_searches to the search endpoint Missing word in changelog
| @elasticsearchmachine run elasticsearch-ci/part-1 |
| @elasticmachine run elasticsearch-ci/part-1 |
| Thank you again @mayya-sharipova, @benwtrent, and @javanna for the reviews! |
This adds basic documentation for the sub_searches top-level element in the search API. (#96224).
This adds basic documentation for the sub_searches top-level element in the search API. (elastic#96224).
This change adds a new top-level element to the search endpoint called
sub_searches. This top-level element allows for a list of additional searches where each "sub search" will have a query executed separately as part of ranking and later combined into a final single set of documents based on the ranking algorithm.The
sub_searcheselement is used instead ofquery(and they may not be used together) to allow a search using ranking to execute multiple queries.An example search using
sub_searcheslooks like: