ZENOTME commented on issue #964:
URL: https://github.com/apache/iceberg-rust/issues/964#issuecomment-2655980835
> > For now, we only support FastAppend. So we can complete the whole
process based on the FastAppend first and complete conflict detection when we
introduce other update actions.
liurenjie1024 commented on issue #964:
URL: https://github.com/apache/iceberg-rust/issues/964#issuecomment-2655890945
> For now, we only support FastAppend. So we can complete the whole process
based on the FastAppend first and complete conflict detection when we introduce
other update acti
ZENOTME commented on issue #964:
URL: https://github.com/apache/iceberg-rust/issues/964#issuecomment-2654352762
Hi, I take some time to figure out the whole commit process. The whole
commit phase can be described as follows:
1. load current metadata from the catalog
2. create UpdateAc
ZENOTME commented on issue #964:
URL: https://github.com/apache/iceberg-rust/issues/964#issuecomment-2653585033
> Thanks [@ZENOTME](https://github.com/ZENOTME) for raising this. The core
part of commit of conflict detection for different isolation levels, which is
quite hard to implement co
liurenjie1024 commented on issue #964:
URL: https://github.com/apache/iceberg-rust/issues/964#issuecomment-2653267313
Thanks @ZENOTME for raising this. The core part of commit of conflict
detection for different isolation levels, which is quite hard to implement
correctly. Retry itself is n
ZENOTME opened a new issue, #964:
URL: https://github.com/apache/iceberg-rust/issues/964
I would like to separate this task into multiple steps:
1. [ ] Identify the RetryableCommitError type.
We can introduce a new `ErrorKind::RetryableCommitError` to abstract
kinds of catalog
