-
Notifications
You must be signed in to change notification settings - Fork 24.9k
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 Get Source API to the HLRC #50885
Add Get Source API to the HLRC #50885
Conversation
8a6fe9a
to
c79ed70
Compare
Pinging @elastic/es-core-features (:Core/Features/Java High Level REST Client) |
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.
Thanks @timoninmaxim for working on this! I left a comment around the request/response class.
* @param options the request options (e.g. headers), use {@link RequestOptions#DEFAULT} if nothing needs to be customized | ||
* @return the response | ||
*/ | ||
public RestResponse getSource(GetRequest getRequest, RequestOptions options) throws IOException { |
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 this api needs to use its own Request and Response class.
Although the get source api support almost all request parameters that the get api support, the get source api doesn't support stored_fields
, version
and version_type
. The latter two may be supported in the future, but I don't see stored_fields
ever be supported (that retrieves something that isn't part of the _source). Also I see that the get api may support doc_value_fields
option to and this is unrelated to the _source like stored_fields
is. Therefor I think that this api should have its own high level client side request class.
I also think that this api should have a dedicated response class, that just includes a Map<String, Object>
field for the source instead of the generic RestResponse
class.
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.
Server's RestGetSourceAction
returns BytesRestResponse
object. Actually HLRC getSouce method returns the same, I just used more generic class for the method signature. Will it be ok to replace RestResponse
with BytesRestResponse
, or Map<String, Object>
is preferable anyway?
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.
Server's RestGetSourceAction returns BytesRestResponse object.
So do many RestAction classes, it is a common way for rest actions to serialize the response to a byte array, so that the networking layer can send a response.
Will it be ok to replace RestResponse with BytesRestResponse, or Map<String, Object> is preferable anyway?
I think if the getSource(...) methods return a Map<String, Object>
then that is ok too, because _source is the only thing that this API returns and the exists(...)
and existsSource(...)
methods in RestHighLevelClient
class also return just a boolean
.
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.
@martijnvg thanks for the clarification! Could I use new GetSourceRequest
class with exists(...)
method too as under the hood they use the same server's API? But it's already released with v6.6.0 (#34519), are we able break compatibility here?
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.
Let's do that in a separate PR. We can then deprecate the old methods in favour for the new methods.
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've committed the requested change. Should I create an issue for change exists(...)
or it's possible to link to this conversation in new PR?
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 need to create an issue for this. You can just mention it in a new PR.
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.
@martijnvg Create PR for that #51789
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.
Left 2 small comments, otherwise LGTM.
return request; | ||
} | ||
|
||
static Request getSource(GetSourceRequest getSourceRequest) { |
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.
Maybe add a test for this in RequestConvertersTests
?
import java.io.IOException; | ||
import java.util.Map; | ||
|
||
public final class GetSourceResponse { |
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 isn't much here, but maybe also add a test for this? You can extend from AbstractResponseTestCase
, this should be straight forward.
@elasticmachine test this please |
b795421
to
eb81a82
Compare
@elasticmachine test this please |
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.
Thanks @timoninmaxim!
When the build is successful then I will merge this.
eb81a82
to
7e7341c
Compare
@elasticmachine test this please |
Hi @martijnvg ! I don't know why those tests are failed, locally they passed successfully. Is it possible to rerun the tests? |
Regarding hlrc module, this did fail:
If you run The |
It's strange. I've run |
@elasticmachine test this please |
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 few comments around the GetSourceResponseTests
test, which failed in CI.
I think that after this, this pr is good to get merged 🤞
|
||
@Override | ||
protected SourceOnlyResponse createServerTestInstance(XContentType xContentType) { | ||
BytesReference source = new BytesArray("{\"field\":\"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.
This should be replaced by:
try (XContentBuilder sourceBuilder = XContentBuilder.builder(xContentType.xContent())) {
sourceBuilder.startObject();
sourceBuilder.field("field", "value");
sourceBuilder.endObject();
return new SourceOnlyResponse(BytesReference.bytes(sourceBuilder));
} catch (IOException ioe) {
throw new UncheckedIOException(ioe);
}
Sometimes the test framework uses a different xcontent type, for example yaml or cbor and this is now hardcoded to json.
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.
Actually this is not needed, because the XContentBuilder#rawValue
invocation in the SourceOnlyResponse#toXContent()
method does the right conversion.
public final class GetSourceResponseTests extends | ||
AbstractResponseTestCase<GetSourceResponseTests.SourceOnlyResponse, GetSourceResponse> { | ||
|
||
static class SourceOnlyResponse implements ToXContent { |
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.
You need to overwrite isFragment()
method here and let it return false
or implement ToXContentObject
instead.
Otherwise the test base class tries to always add a json object, which is already added in this test.
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 you're correct, I've just did it and send new commit
expected.put("field", "value"); | ||
|
||
assertThat(clientInstance.getSource(), equalTo(serverTestInstance.source)); | ||
assertThat(clientInstance.getSource(), equalTo(expected)); |
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.
The body of this method can be replaced with: assertThat(clientInstance.getSource(), equalTo(Map.of("field", "value")));
. Just checking for the expected map is sufficient here.
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 it too
1a578ac
to
bfa0cd9
Compare
@elasticmachine test this please |
@elasticmachine run elasticsearch-ci/default-distro |
Add Get Source API to the HLRC
relates: #47678