jackye1995 commented on code in PR #5888:
URL: https://github.com/apache/iceberg/pull/5888#discussion_r983805711
##########
core/src/main/java/org/apache/iceberg/BaseTransaction.java:
##########
@@ -479,6 +480,52 @@ private void applyUpdates(TableOperations underlyingOps) {
// Cannot pass even with retry due to conflicting metadata changes.
So, break the
// retry-loop.
throw new PendingUpdateFailedException(e);
+
+ } catch (ValidationException e) {
+ if (PropertyUtil.propertyAsBoolean(
+ base.properties(),
+ TableProperties.ROLLBACK_COMPACTION_ON_CONFLICTS_ENABLED,
+
TableProperties.ROLLBACK_COMPACTION_ON_CONFLICTS_ENABLED_DEFAULT)) {
+
+ // use refreshed metadata
+ this.base = underlyingOps.current();
+ this.current = underlyingOps.current();
+ Long rollbackToSnapshotId = current.currentSnapshot().parentId();
+ long currentSnapshotId = current.currentSnapshot().snapshotId();
+ boolean updatesAppliedSuccessfully = false;
+
+ while (rollbackToSnapshotId != null
+ && !updatesAppliedSuccessfully
+ && PropertyUtil.propertyAsBoolean(
Review Comment:
I discussed with you a bit offline as well, I think instead of introducing a
new property of `is-compacted`, it seems like we can rollback whenever we have
conflict and
`current.snapshot(currentSnapshotId).equals(DataOperations.REPLACE)`? Which
applies to both compaction and rewrite manifests and feels more generic. Is
there any risk of doing that way?
--
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
