dimas-b commented on code in PR #1378:
URL: https://github.com/apache/polaris/pull/1378#discussion_r2047946624
##########
service/common/src/main/java/org/apache/polaris/service/catalog/iceberg/IcebergCatalog.java:
##########
@@ -1328,6 +1344,25 @@ public void doCommit(TableMetadata base, TableMetadata
metadata) {
String newLocation = writeNewMetadataIfRequired(base == null, metadata);
String oldLocation = base == null ? null : base.metadataFileLocation();
+ // TODO: we should not need to do this hack, but there's no other way to
modify
+ // metadataFileLocation / currentMetadataLocation
+ if (updateMetadataOnCommit) {
+ try {
+ Field tableMetadataField =
TableMetadata.class.getDeclaredField("metadataFileLocation");
+ tableMetadataField.setAccessible(true);
+ tableMetadataField.set(metadata, newLocation);
Review Comment:
Thanks for the info. All is clear up to `requestRefresh()`. Yet, this call
alone will not cause the metadata to be reloaded. What actually initiates the
reload?
Re: `currentMetadataLocation` in Iceberg code and related logic. I would not
say it does not handle it properly. I believe the rationale is that after a
commit the TableOperations object cannot predict the outcome, so it must
reload. As an example, the Catalog (from Iceberg's perspective) may alter
metadata on commit. Polaris is a catalog by itself, but the code we reuse here
is written with the assumptions of running on the client side, I believe.
--
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: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
