-
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
Replace IndexAlreadyExistsException with ResourceAlreadyExistsException #21494
Replace IndexAlreadyExistsException with ResourceAlreadyExistsException #21494
Conversation
Note that in 6.0 we could decide to delete the Index*AlreadyExistsException classes. We'd still need to keep them in 5.x for backwards compatibility. Let me know what you think and I'll adjust the PR respectively. |
} | ||
|
||
@Override | ||
public RestStatus status() { |
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 wonder if it'd be more right to make this final
.
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.
With the implication that all not found exceptions are 400
errors and IndexShardAlreadyExistsException
isn't really an ResourceAlreadyExistsException
because it is an internal error.
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 how I had it originally. Then I had a brain split about whether IndexShardAlreadyExistsException
is actually a ResourceAlreadyExistsException
. I am happy to change this, but I'll wait a bit in case more opinions are voiced.
I think that @s1monw's thinking should be taken into consideration before this PR is integrated. |
I think this PR should remove all the exceptions and replace it by |
There are a few points here that I would like to understand better:
|
…istsException` Both exception can be replaced with java built-in exception, IAE and ISE respectively. This should be backported partially to 5.x which the transport layer code should be preserved. Relates to elastic#21494
lets not worry about this for now
I just looked into the code and replaced
so on the wire protocol it will be just fine since we are not name-aware, we use an integer ID to deserialize. If you are thinking of REST layer we can just do something like this: /*
* Licensed to Elasticsearch under one or more contributor
* license agreements. See the NOTICE file distributed with
* this work for additional information regarding copyright
* ownership. Elasticsearch licenses this file to you under
* the Apache License, Version 2.0 (the "License"); you may
* not use this file except in compliance with the License.
* You may obtain a copy of the License at
*
* http://www.apache.org/licenses/LICENSE-2.0
*
* Unless required by applicable law or agreed to in writing,
* software distributed under the License is distributed on an
* "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
* KIND, either express or implied. See the License for the
* specific language governing permissions and limitations
* under the License.
*/
package org.elasticsearch.indices;
import org.elasticsearch.ElasticsearchException;
import org.elasticsearch.common.io.stream.StreamInput;
import org.elasticsearch.index.Index;
import org.elasticsearch.rest.RestStatus;
import java.io.IOException;
public class ResourceAlreadyExistsException extends ElasticsearchException {
public ResourceAlreadyExistsException(Index index, String message) {
super(message);
setIndex(index);
}
public ResourceAlreadyExistsException(StreamInput in) throws IOException{
super(in);
}
@Override
public RestStatus status() {
return RestStatus.BAD_REQUEST;
}
@Override
protected String getExceptionName() {
if (getIndex() != null) {
// this is only for BWC and can be removed in 6.0.0
return "index_already_exists_exception";
} else {
return super.getExceptionName();
}
}
} |
Sounds good, I will update the PR. I summarise the decision as I understand it:
|
++ sounds good to me @jasontedor @nik9000 WDYT? |
Makes sense to me. |
+1 |
21edd06
to
0afd6ad
Compare
PR is now updated with latest plan. |
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 one comment otherwise looks good
@@ -745,7 +745,7 @@ public void testIds() { | |||
ids.put(120, org.elasticsearch.repositories.RepositoryVerificationException.class); | |||
ids.put(121, org.elasticsearch.search.aggregations.InvalidAggregationPathException.class); | |||
ids.put(122, null); | |||
ids.put(123, org.elasticsearch.indices.IndexAlreadyExistsException.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.
this doesn't work sorry... you can't add a new exception here it's a wire protocol break. Just reuse the 123 and add a comment that we renamed 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.
Good to know! Will change ASAP.
3ff0b48
to
06e2054
Compare
for the backport I think we need to add a BWC layer here other than that this change LGTM... |
I opened a backport PR at #21601. |
06e2054
to
1561ecd
Compare
1561ecd
to
c1f95f6
Compare
For those wondering how this turned out, yes it did break backwards compatibility for us as an ES API consumer. |
will rpm of version 6 with this change: a75320f soon be available in your yum repo |
Similar to ResourceNotFoundException, a generic ResourceAlreadyExistsException will reduce the need to introduce an additional exception for each type of resource that can have that error.
At the moment, there is:
This commit changes those to inherit ResourceAlreadyExistsException
as removing them would cause backwards compatibility problems.