dramaticlly commented on code in PR #12228:
URL: https://github.com/apache/iceberg/pull/12228#discussion_r2078186104
##########
api/src/main/java/org/apache/iceberg/catalog/Catalog.java:
##########
@@ -344,6 +344,25 @@ default void invalidateTable(TableIdentifier identifier) {}
* @throws AlreadyExistsException if the table already exists in the catalog.
*/
default Table registerTable(TableIdentifier identifier, String
metadataFileLocation) {
+ return registerTable(
+ identifier, metadataFileLocation, false /* register only if it does
not exist */);
+ }
+
+ /**
+ * Register a table with the catalog, optionally overwrite existing table
metadata.
+ *
+ * <p><strong>Note:</strong> Overwriting an existing table may result in the
change of table UUID,
+ * to match the one in the metadata file.
+ *
+ * @param identifier a table identifier
+ * @param metadataFileLocation the location of a metadata file
+ * @param overwrite if true, overwrite the existing table with provided
metadata
+ * @return a Table instance
+ * @throws AlreadyExistsException if the table already exists in the catalog
and overwrite is
+ * false.
+ */
+ default Table registerTable(
+ TableIdentifier identifier, String metadataFileLocation, boolean
overwrite) {
throw new UnsupportedOperationException("Registering tables is not
supported");
Review Comment:
Thanks @RussellSpitzer , in this PR I introduced a new register-overwrite
API on catalog interface, and changed as new base for register-table (where it
can call the new API with overwrite=false).
## Before:
default register-table API throw UnsupportedOperationException
## After:
default register-table API -> register-overwrite(overwrite=true)
default register-overwrite API throw UnsupportedOperationException
---
The benefits are all concrete catalog implementations can just implement the
new API and interface is only used for delegation between the 2 APIs. This is
an easier to reason (as all register logic sits in one place) and follows the
convention like drop-table and drop-table-purge.
The potential downside is that some custom catalog implementations outside
iceberg repo who implements the register-table API, might need to update their
code when upgrades iceberg dependency with the interface change. I feel like
it's generally justified for customized catalog to keep up with iceberg
interface change. Please let me know if you think otherwise.
--
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
