Add Index API to High Level Rest Client#23040
Conversation
There was a problem hiding this comment.
can you make this change separately please? It will need to be backported , while this PR targets master only and should only change stuff under rest-high-level.
There was a problem hiding this comment.
Sure - this part has been removed from the PR, I'll create another PR for the WriteRequest changes.
e227619 to
3f8dc3c
Compare
|
Code rebased and updated |
There was a problem hiding this comment.
This might be paranoid, but in case some other previous call to the builder set this to some other value, can we remove that value from the map in case it is set to NONE later?
There was a problem hiding this comment.
Scratch that, I see this is private and only used internally, and the request only has one of each parameters, so duplicate calls are unlikely. Just me being paranoid.
There was a problem hiding this comment.
Paranoid is good sometimes :) You're right, I'll improve that in order to be remove the value in case of NONE.
There was a problem hiding this comment.
shall we rather have a check in putParam for the return value and assert that the value should never be there. If it is it's our bug right?
There was a problem hiding this comment.
Maybe we can replace calls of this helper with the new Endpoint class? Might get a tad bit longer in the end, so I'm fine either way.
There was a problem hiding this comment.
Yes we can. I'm also waiting for Luca opinion on those Endpoint/Params classes, but if he likes it I'll move those as well.
There was a problem hiding this comment.
feel free to unify this with what you do with index. I like these changes overall, I left one comment on the endpoint part which may help improving things a bit, that's it.
There was a problem hiding this comment.
Nit: maybe move this up next to the other methods (ping/exists/get) that output new Requests.
There was a problem hiding this comment.
Previous test tries all content Types, this one random choice only. Any reason for this?
There was a problem hiding this comment.
Not, it's a leftover in the previous test, XContent type must be chosen randomly at the beginning of all tests. I changed that.
There was a problem hiding this comment.
Would not setting the version at all be valid here? If so, maybe also test this (e.g. rarely?)
There was a problem hiding this comment.
I don't know if it is compatible, but maybe you can use RandomObjects#randomSource(Random random) here instead?
javanna
left a comment
There was a problem hiding this comment.
left a few comments but no blockers, LGTM
There was a problem hiding this comment.
given that we build a url, do we really need two constants for the same thing?
There was a problem hiding this comment.
I changed to
private static final String DELIMITER = "/";
private String prefix = DELIMITER;
private String suffix = "";and also added a withPrefix method that was missing. I find it useful for building endpoints for Snapshot/Restore: /_snapshot could be defined as a prefix. Just a matter of taste
There was a problem hiding this comment.
Actually, I removed all this stuff in favor of a simple concatenating method helper.
There was a problem hiding this comment.
shall we make it accept a varargs instead and make this a single line?
There was a problem hiding this comment.
given that the suffix is also known before we go and provide index, type, and id... (even in case of e.g. _search) I wonder if we can get rid of the list, and just provide parts and suffix as constructor argument, then convert it into string straightaway. Not even sure we need a builder for this.
There was a problem hiding this comment.
shall we rather have a check in putParam for the return value and assert that the value should never be there. If it is it's our bug right?
There was a problem hiding this comment.
Use HttpPut.METHOD_NAME maybe? or define our own constants?
There was a problem hiding this comment.
feel free to unify this with what you do with index. I like these changes overall, I left one comment on the endpoint part which may help improving things a bit, that's it.
This commit adds support for the Index API in the High Level Rest Client.
3f8dc3c to
269e377
Compare
|
@cbuescher @javanna Thanks for the reviews. I updated the code according to your comments. I also had to rebase in order to use #23106 |
|
Thanks @cbuescher @javanna |
This commit adds support for the Index API in the High Level Rest Client.
It changes few things in the way request's parameters map is created in the high level client and changea bit RefreshPolicy in core.