Hey Iceberg Experts: I am seeking assistance and insights regarding an issue we’ve encountered with RESTTableOperations and its inability to support on-demand table metadata swaps. We are currently adopting the REST-based catalog from Hive and have noticed a potential gap in the TableOperations.commit() API. Typically, we use the commit API to revert a table to a previously known state, as demonstrated below:
String deisredMetadataPath = "/var/newdb/table/metadata/00003-579b23d1-4ca5-4acf-85ec-081e1699cb83.metadata.json"" ops.commit(ops.current(), TableMetadataParser.read(ops.io(), dedeisredMetadataPath)); However, this approach is no longer working with the REST-based catalog. I suspect that the issue may be related to how the update type is modeled in RESTTableOperations. I have shared a unit test that reproduces the problem on https://github.com/apache/iceberg/issues/12134, where it works on JDBC and in-memory catalogs, but not with RESTCatalog. Best Regards, Steve Zhang
