-
Notifications
You must be signed in to change notification settings - Fork 25k
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
REST high-level client: add support for exists alias #28332
REST high-level client: add support for exists alias #28332
Conversation
@olcbean given that you are working on adding support for update aliases, maybe you want to review this one? |
// end::exists-alias-execute | ||
assertTrue(exists); | ||
|
||
// tag::exists-alias-execute-async |
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.
Shouldn't the change made by #27899 be applied to Exists Alias (and indeed Open Index and Close Index, which were presumably merged later) as well?
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.
yea probably, I will sync with @tlrx who has made that change. thanks for catching 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.
That would be better, yes
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 am wondering though: the original problem was that we were creating/deleting indices asynchronously, hence we would have to wait for such operation to be completed.
Do we have to wait for any other async operation like open/close index etc.? I would say no but maybe @tlrx can confirm.
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 don't think it's important for the Exist Alias API as it does not modify the cluster state or requires a lock on shards, but for the open/close ones it might be necessary yes.
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 will make that change to open/close separately 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.
LGTM. Left a few minor nits
@@ -157,4 +160,26 @@ public void closeAsync(CloseIndexRequest closeIndexRequest, ActionListener<Close | |||
restHighLevelClient.performRequestAsyncAndParseEntity(closeIndexRequest, Request::closeIndex, CloseIndexResponse::fromXContent, | |||
listener, Collections.emptySet(), headers); |
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 we change it to emptySet()
as below?
@@ -156,7 +157,7 @@ static Request openIndex(OpenIndexRequest openIndexRequest) { | |||
} | |||
|
|||
static Request closeIndex(CloseIndexRequest closeIndexRequest) { | |||
String endpoint = endpoint(closeIndexRequest.indices(), Strings.EMPTY_ARRAY, "_close"); | |||
String endpoint = endpoint(closeIndexRequest.indices(), "_close"); |
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! Makes things easier :) Could you do the same for createIndex
and deleteIndex
?
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
GetAliasesRequest getAliasesRequest = new GetAliasesRequest("alias"); | ||
assertFalse(execute(getAliasesRequest, highLevelClient().indices()::existsAlias, highLevelClient().indices()::existsAliasAsync)); | ||
|
||
client().performRequest("PUT", "/index"); |
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 is a utility createIndex
. Should we use it instead?
GetAliasesRequest getAliasesRequest = new GetAliasesRequest(); | ||
String[] indices = randomIndicesNames(0, 5); | ||
getAliasesRequest.indices(indices); | ||
String[] aliases = randomIndicesNames(0, 5); |
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 this be randomIndicesNames(1, 5)
instead?
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 the idea was to also test the case where the aliases array is empty, that is supported and should be interpreted as "all aliases"
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 though this for GET
rather than for HEAD
? In the specs the alias is set to required
. Am I missing something?
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 SPEC may be outdated. the code and behaviour is the same for HEAD or GET in the server side, we just don't return a response body when HEAD is used.
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.
Oh, I see now.. My point was for the corner case when there is no alias and no index, then only GET _alias
is supported, isn't it?
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 are right, thanks for pointing this out.
static String endpoint(String[] indices, String endpoint) { | ||
return buildEndpoint(String.join(",", indices), endpoint); | ||
} | ||
|
||
static String endpoint(String[] indices, String[] types, String endpoint) { |
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.
AFAIK in 7.0 multiple types are no longer supported.
I am not really sure it is nice to offer the possibility to use multiple types. What do you think?
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.
that is the plan, but we are not there yet. What we currently do in the client is aligned with what the API supports. Once the API will change, it will be time to also update the client.
With the last commit I addressed all the comments that I got till now. |
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.
LGTM, left some minor comments
setRandomIndicesOptions(getAliasesRequest::indicesOptions, getAliasesRequest::indicesOptions, expectedParams); | ||
|
||
Request request = Request.existsAlias(getAliasesRequest); | ||
StringJoiner endpoint = new StringJoiner("/", "/", ""); |
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.
Nit: could it be renamed to expectedEndpoint
?
-------------------------------------------------- | ||
include-tagged::{doc-tests}/IndicesClientDocumentationIT.java[exists-alias-request-alias] | ||
-------------------------------------------------- | ||
<1> One or more aliases to look for |
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.
Nit: extra space
==== Exists Alias Response | ||
|
||
The Exists Alias API returns a `boolean` that indicates whether the provided | ||
alias (or aliases) were found or not. |
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.
Nit: was instead or were?
retest this please |
edd0e06
to
0f32d21
Compare
* 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) ...
Relates to #27205