- Notifications
You must be signed in to change notification settings - Fork 25.6k
Initial Search Application Search API with templates #94869
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
Initial Search Application Search API with templates #94869
Conversation
…ate as a separate field
…emplate parameters
| ] | ||
| privileges: [ "manage" ] | ||
| - names: [ | ||
| # indices used for indexing and searching |
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.
Some indices for the search use case, with read and write permissions
| * @param searchApplicationTemplate The search application template to be used on search | ||
| */ | ||
| public SearchApplication(String name, String[] indices, @Nullable String analyticsCollectionName, long updatedAtMillis) { | ||
| public SearchApplication( |
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.
A little messy rebase on the ent-search-module branch 😱 . Added the Search Template to the application.
| | ||
| import static org.elasticsearch.xcontent.ConstructingObjectParser.optionalConstructorArg; | ||
| | ||
| public class SearchApplicationQueryParams implements ToXContentObject, Writeable { |
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.
Created a new class for the query parameters. Just now it's simple enough, but we could potentially extend it with other options / params in the future, so I decided to create a separate class for handling 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.
Can it be implemented in the Request directly? The other params you're talking about are would be for the request so I guess we can add everything there?
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 think you're right. Changed it to be included in the Request.
| @Override | ||
| protected RestChannelConsumer prepareRequest(RestRequest restRequest, NodeClient client) throws IOException { | ||
| SearchApplicationQueryParams queryParams = new SearchApplicationQueryParams(); | ||
| if (restRequest.hasContent()) { |
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 leaves open the possibility of not including a body at all, and just issue the request with no body.
| @@ -0,0 +1,40 @@ | |||
| { | |||
| "search_application.query": { | |||
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 the name of this API be search_application.search to match the path?
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.
Good catch!
Right now, it matches the action names (RestQuerySearchApplicationAction, QuerySearchApplicationAction, TransportQuerySearchApplicationAction). I guess Query is a better name as SearchSearchApplicationAction would be very confusing.
I'm in favour of refactoring these names and drop the SearchApplication from them, but that's something that can wait for later.
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.
Changed to search_application.search, thanks for the discussion @sethmlarson !
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.
Looks great @carlosdelest! I left some minor comments.
| | ||
| import static org.elasticsearch.xcontent.ConstructingObjectParser.optionalConstructorArg; | ||
| | ||
| public class SearchApplicationQueryParams implements ToXContentObject, Writeable { |
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.
Can it be implemented in the Request directly? The other params you're talking about are would be for the request so I guess we can add everything there?
...h/src/main/java/org/elasticsearch/xpack/application/search/SearchApplicationQueryParams.java Outdated Show resolved Hide resolved
...arch/src/main/java/org/elasticsearch/xpack/application/search/SearchApplicationTemplate.java Outdated Show resolved Hide resolved
...arch/src/main/java/org/elasticsearch/xpack/application/search/SearchApplicationTemplate.java Show resolved Hide resolved
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.
Looks great! One change that needs to happen in QuerySearchApplicationAction, everything else is non-blocking nitpicky comments. Thank you!
rest-api-spec/src/main/resources/rest-api-spec/api/search_application.search.json Show resolved Hide resolved
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.
Nice additions to this yaml test. Do we want a specific test for success when no template is specified? (Maybe it's not strictly necessary since it's implicitly tested in the GET yaml tests?)
| name: test-search-application | ||
| | ||
| - match: { hits.total.value: 2 } | ||
| - match: { hits.hits.0._id: "doc1" } |
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.
Is there any risk of test stability here, if the two correct results are returned in a different order than we expect? Do we want to consider maybe verifying that the two docIds were returned, not the order?
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.
Nice tests! Do we want to consider adding a test case for inputting an invalid template value (such as in your demo)? Or is that taken care of sufficiently elsewhere?
.../main/java/org/elasticsearch/xpack/application/search/action/GetSearchApplicationAction.java Show resolved Hide resolved
.../main/java/org/elasticsearch/xpack/application/search/action/GetSearchApplicationAction.java Show resolved Hide resolved
...ain/java/org/elasticsearch/xpack/application/search/action/QuerySearchApplicationAction.java Show resolved Hide resolved
| | ||
| public class TransportQuerySearchApplicationAction extends SearchApplicationTransportAction< | ||
| QuerySearchApplicationAction.Request, | ||
| SearchResponse> { |
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 think it's OK to return a SearchResponse in this PR, but some day in the future we may want to tack on additional data to a custom response that includes a search response.
...org/elasticsearch/xpack/application/search/action/TransportQuerySearchApplicationAction.java Show resolved Hide resolved
| randomFrom(new String[] { null, randomAlphaOfLengthBetween(1, 10) }), | ||
| randomLongBetween(0, Long.MAX_VALUE) | ||
| randomLongBetween(0, Long.MAX_VALUE), | ||
| randomBoolean() ? getRandomSearchApplicationTemplate() : 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.
Nice 👍
Adds a search endpoint to Search Applications:
GET /_application/search_application/<name>/_search{ "params": { "param1": "value1", "param2": "value2" } }where
paramscontains overrides for the Search Application defined template, for example:PUT /_application/search_application/<name>{ "indices": ["test1"], "template": { "script": { "source": { "query": { "term": { "{{param1}}": "{{param2}}" } } }, "params": { "param1": "hello", "param2": "world" } } } }For the above Search Application and search request, the template would render like:
... as the search specified parameters would override the template ones.
Based on this work by Jim and Ioana 💯