>
> Hi Dzeri,
>
> Thanks for raising this. I wrote the PR that introduced appendUpdate
> (#13631), happy to share some context.
>
> First question: can your conflict detection and resolution semantics be
> expressed with SnapshotAncestryValidator? Dan added that hook in the 1.11
> release as public API on SnapshotUpdate. It runs after the metadata
> refresh, fire on every commit retry, including the transaction retry path.
> That would be the preferred approach if validation only needs to inspect
> the refreshed table state and reject.
>
> If a custom PendingUpdate is a must, some of what you described is already
> reachable, like the transaction's TableOperations can be exposed through
> `((HasTableOperations)
> txn.table()).operations()`.
>
> On making appendUpdate public, I got pushback on that in the past: the
> wiring of an update into a transaction should stay protected, since that is
> where cleanup and retry are handled. A lighter alternative to reflection is
> a split-package shim. One can have a small class declared in package
> org.apache.iceberg inside your own jar.
>
> Happy to learn more about your custom update and see if there is a
> generalizable way to extend this, beyond what RowDelta and OverwriteFiles
> can express today.
>
> Thanks,
> Hongyue Zhang
