feat(transaction): Add TransactionAction POC

[CTTY]

Which issue does this PR close?

Related Issues:

• [EPIC] Support for appending data to iceberg table. #1382 [EPIC]
• Add a method in TableCommit to apply changes to TableMetadata to create a new TableMetadata #1386
• Add retry in Transaction::commit method #1387
• Implement saving TableMetadata to new location. #1388
• Swith metadata pointer to new location for different catalogs(sql, hive, glue, etc) #1389

What changes are included in this PR?

Are these changes tested?

[liurenjie1024]

Left some suggestions.

[CTTY]

Hi @liurenjie1024 @ZENOTME ,

Thanks for the feedback! I took another look at the transaction code path implementation in Java today and had some additional thoughts.

• PendingUpdate#apply:

  • Responsible for building the item T, if it hasn't been built yet.

  • (In the case of SnapshotProducer) It validates table history.

  • Generates updated manifest lists and writes them to disk.

  • Returns the generic item T held by the PendingUpdate.

• PendingUpdate#commit:

  • Retrieves T, which may come from apply() or be built during commit().

  • Builds new metadata based on the base table, and applies T to generate staging metadata.

  • (For SnapshotProducer) Asks the catalog to commit the updated metadata — i.e., flush it to disk and update the catalog pointer to the new metadata.

Mapping to Rust's TransactionAction:

• TransactionAction::apply() should:

  • Build the item T, if needed.

  • Run SnapshotProduceAction::apply() to validate history and write updated manifest lists.

  • Return the intermediate result T.

• TransactionAction::commit() should:

  • Retrieve T.

  • Generate staging metadata by updating Transaction.current_table, Transaction.updates, and Transaction.requirements.

  • If needed, call SnapshotProduceAction::commit() → Catalog::update_table().

I've updated my code to add Transaction::apply to be more aligned with the Java semantics. Please take a look! The current changes are still based on UpdateLocationAction, which is relatively simple. I'm trying to make the API usages as close to the Java version as possible (like this)
Next, I plan to apply this structure to more complex actions like fast append. Please let me know your thoughts!

[liurenjie1024]

Hi, @CTTY I think we should seperate our concerns here. Our design could be inspired by java, but it doesn't mean we should blindly copy java's class hierarchy. There are a lot of differences between these two languages. The T apply() method in java is quite convenient since java's language elements facilities such complex class hierarchies, but this is not the case for rust.

I don't think it's a good idea to add an apply method in the general purpose TransactionAction. TransactionAction is used to be stored in Transaction so that we could do retry when commit exception, so commit is the only method required. In future we may have some type safe trait for actions which may produce new snapshot, but this is not the concern in this pr.

[ZENOTME]

Hi, @CTTY I think we should seperate our concerns here. Our design could be inspired by java, but it doesn't mean we should blindly copy java's class hierarchy. There are a lot of differences between these two languages. The T apply() method in java is quite convenient since java's language elements facilities such complex class hierarchies, but this is not the case for rust.

I don't think it's a good idea to add an apply method in the general purpose TransactionAction. TransactionAction is used to be stored in Transaction so that we could do retry when commit exception, so commit is the only method required. In future we may have some type safe trait for actions which may produce new snapshot, but this is not the concern in this pr.

+1 for we don't need to apply now. In iceberg-java, the apply can be used for code reuse. E.g. SnapshotProducer implements apply and commit, and CherryPickOperation inherits from SnapshotProducer, overwrites the apply but reuses the commit. But we can't do this in Rust.

[CTTY]

Discussed with @liurenjie1024 offline, and we are aligned on the general approach demonstrated here to refactor the transaction commit path and enable retry

Next, I'll break this PR into smaller ones and incrementally merge the code~

[Xuanwo]

We need to use downcast_ref because do_commit returns an anyhow::Error. If we update the API for do_commit to return an iceberg::Error instead, I believe it would make things clearer.