Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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
Add async_search.submit to HLRC #53592
Add async_search.submit to HLRC #53592
Changes from 2 commits
a147c41
ebf5428
0ed46e6
701793e
089485b
87a4f92
207441d
8f708af
b7d6f14
68baeb9
94083b6
0796651
310fdee
7e02579
c88625a
3e5a33f
594a5eb
f686a50
1d301c4
4ab7dc7
720c966
220e6a8
1d0b59c
ebd1906
f65cf82
841430e
7d3a8ed
8223989
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
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 that whether or not to expose the inner search request was discussed in previous reviews. I am confused though on what direction was chosen. I see that the getters and setters from the search request are copied to the async request, but the inner search request is still exposed through this getter and can be modified directly. Didn't we want to rather hide it from users?
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.
+1 to hide
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.
Okay, I will look into that. Will make testing a bit more awkward though because I can't reuse some existing infra then.
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.
package protected ? ;)
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.
Would work but then I need to move some classes around. I'd prefer that to adding all those getters to the submit request.
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 is proving to be tricky. I cannot easily move the AsyncSearchRequestConverters out of the
org.elasticsearch.client
package since they need package private infra from RequestConverters. I can probably move theSubmitAsyncSearchRequest
into that package though, will take a look what that would change.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 pushed f686a50 which moves the new request and response classes into
org.elasticsearch.client
to be able to use a package protectedgetSearchRequest()
to avoid all the boilerplate getters on the new request. I'm unsure what I like best, take a look and let me know which direction you are leaning.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 no getter is safer. We also do have extra protection on the server side for unsupported values but I think the client should never allow to send unsupported values.
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 agree with Luca, we should avoid the getter on the search request. However, we should have a getter for all options that we expose so I don't see why you want to avoid them ? If we have a setter, we need to provide a way to access the value.
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, I reverted that change back to the one where I removed
getSearchRequest
and added a bunch of getters.