Add Indices Aliases API to the high level REST client#27876
Add Indices Aliases API to the high level REST client#27876javanna merged 4 commits intoelastic:masterfrom
Conversation
|
Since this is a community submitted pull request, a Jenkins build has not been kicked off automatically. Can an Elastic organization member please verify the contents of this patch and then kick off a build manually? |
1c47099 to
7e03951
Compare
|
@elasticmachine test this please |
|
Since this is a community submitted pull request, a Jenkins build has not been kicked off automatically. Can an Elastic organization member please verify the contents of this patch and then kick off a build manually? |
|
@olcbean thanks for taking this on, I hope I will be able to look at it shortly. In the meanwhile, could you rebase your branch, unfortunately the "core" project was renamed to "server" in the meantime so the changes in core while have conflicts. Hopefully a simple rebase is enough. |
7e03951 to
9257fc7
Compare
|
@cbuescher thanks for picking this one up! I just rebased |
|
@elasticmachine test this please |
There was a problem hiding this comment.
In our SPEC we call this update_aliases. Can you rename these new methods to updateAliases please?
There was a problem hiding this comment.
To be honest I struggled with the naming here..
AFAICS the rest specs are referring to it as update_aliases, the IndicesAdminClient uses aliases, ( as the end point itself is aliases ), and the corresponding request and response are respectively IndicesAliasesRequest and IndicesAliasesResponse. So I was somewhat reluctant to bring a new updateAliases into the mix.
There was a problem hiding this comment.
yea I hear you. This comes from the fact that Java was always a special client. I think it makes sense to follow the SPEC convention at this point. Although the request and response follow a different one. We can always rename them later.
There was a problem hiding this comment.
what did you mean to do with the randomization? I wonder if it gets too complicated with multiple randomized actions...
There was a problem hiding this comment.
check that 0 and multiple it is still OK. Should I go back to a single action only?
There was a problem hiding this comment.
maybe, I mean in this unit test randomizing the request body so heavily may not make a huge difference. I don't have a strong opinion though, what do you think?
There was a problem hiding this comment.
here too, let's call it update aliases like in the SPEC?
There was a problem hiding this comment.
should this be builder.array ?
There was a problem hiding this comment.
thanks a lot for adding this, I know the effort it took code-wise :)
There was a problem hiding this comment.
how about folding this into AliasActionsTests and remove randomization from RequestTests? just an idea, let me know what you think.
There was a problem hiding this comment.
I see some duplication her between the newly added generator and this method. Maybe we can address that too?
There was a problem hiding this comment.
I wonder if we should explain here the feature/API itself or rather just mention how to use it and point to the API docs to know more about it. What do you think about rephrasing to just say e.g. "use this to set a routing value" etc. without explaining what routing is in this page?
There was a problem hiding this comment.
Do you mean to follow the low level client docs approach? Just say how to use requests / responses with a few examples.
Or do you mean to have a simple example for every supported API with a request / response and a link to the API docs?
There was a problem hiding this comment.
besides the link, I wouldn't explain here what the API does and how the different options work. Just how to use the options with the client. At least I think this is what we've done until now. Makes sense?
|
@javanna I just pushed a commit to address your comments. Can you have a look? ( I did not rename the asciidoc to |
javanna
left a comment
There was a problem hiding this comment.
I left two tiny comments, LGTM otherwise.
There was a problem hiding this comment.
here can we just describe how to add a filter rather than describing what filters do and where they get applied?
|
@javanna have another look? |
|
looks good @olcbean , just needs rebasing/merging master in |
bf3d6b6 to
28a8dc6
Compare
|
@javanna I just rebased and changed the docs as well ;) |
|
test this please |
|
thanks @olcbean ! |
* master: (23 commits) Update Netty to 4.1.16.Final (elastic#28345) Fix peer recovery flushing loop (elastic#28350) REST high-level client: add support for exists alias (elastic#28332) REST high-level client: move to POST when calling API to retrieve which support request body (elastic#28342) Add Indices Aliases API to the high level REST client (elastic#27876) Java Api clean up: remove deprecated `isShardsAcked` (elastic#28311) [Docs] Fix explanation for `from` and `size` example (elastic#28320) Adapt bwc version after backport elastic#28358 Always return the after_key in composite aggregation response (elastic#28358) Adds test name to MockPageCacheRecycler exception (elastic#28359) Adds a note in the `terms` aggregation docs regarding pagination (elastic#28360) [Test] Fix DiscoveryNodesTests.testDeltas() (elastic#28361) Update packaging tests to work with meta plugins (elastic#28336) Remove Painless Type from MethodWriter in favor of Java Class. (elastic#28346) [Doc] Fixs typo in reverse-nested-aggregation.asciidoc (elastic#28348) Reindex: Shore up rethrottle test Only assert single commit iff index created on 6.2 isHeldByCurrentThread should return primitive bool [Docs] Clarify `html` encoder in highlighting.asciidoc (elastic#27766) Fix GeoDistance query example (elastic#28355) ...
Add Indices Aliases API to the high level REST client
Relates to #27205