adutra commented on code in PR #8909:
URL: https://github.com/apache/iceberg/pull/8909#discussion_r1376237462
##########
nessie/src/main/java/org/apache/iceberg/nessie/NessieTableOperations.java:
##########
@@ -135,71 +135,26 @@ protected void doCommit(TableMetadata base, TableMetadata
metadata) {
boolean newTable = base == null;
String newMetadataLocation = writeNewMetadataIfRequired(newTable,
metadata);
- String refName = client.refName();
- boolean failure = false;
+ AtomicBoolean failure = new AtomicBoolean(false);
try {
String contentId = table == null ? null : table.getId();
client.commitTable(base, metadata, newMetadataLocation, contentId, key);
- } catch (NessieConflictException ex) {
- failure = true;
- if (ex instanceof NessieReferenceConflictException) {
- // Throws a specialized exception, if possible
- maybeThrowSpecializedException((NessieReferenceConflictException) ex);
+ } catch (NessieConflictException | NessieNotFoundException |
HttpClientException ex) {
+ NessieUtil.handleExceptionsForCommits(ex, client.refName(), failure);
+ } catch (NessieBadRequestException ex) {
Review Comment:
> I think the proper way to fix it is to check if any different kind of
content exist for the key while committing this key in doCommit() of
NessieTableOperation and NessieViewOperation. But that is an extra round trip
with server and might degrade commit performance slightly?
This solution is viable but would imho be less efficient since, as you
mentioned, it involves an extra roundtrip.
I personally think that if `NessieTableOperation` could "memorize" the
commit hash of that last time it did a refresh, then reuse it to commit the
table changes, that would solve the problem in a better way since it does not
involve fetching contents.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@iceberg.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@iceberg.apache.org
For additional commands, e-mail: issues-h...@iceberg.apache.org
