-
Notifications
You must be signed in to change notification settings - Fork 5.5k
[Iceberg]Support renaming table on hive file catalog #24312
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Iceberg]Support renaming table on hive file catalog #24312
Conversation
7cd47c9 to
366408c
Compare
...-hive-metastore/src/main/java/com/facebook/presto/hive/metastore/file/FileHiveMetastore.java
Outdated
Show resolved
Hide resolved
...-hive-metastore/src/main/java/com/facebook/presto/hive/metastore/file/FileHiveMetastore.java
Outdated
Show resolved
Hide resolved
ZacBlanco
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think the changes are fine, however the code complexity seems high due to all the nested conditionals. I would consider factoring out some methods or subclassing as mentioned in my comment.
| try { | ||
| if (!metadataFileSystem.rename(getTableMetadataDirectory(databaseName, tableName), getTableMetadataDirectory(newDatabaseName, newTableName))) { | ||
| throw new PrestoException(HIVE_METASTORE_ERROR, "Could not rename table directory"); | ||
| if (!isIcebergTable(table)) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think we need to do it for this PR, but all these conditionals make me think that it is worth considering to subclass the FileHiveMetastore and create a FileIcebergHiveMetastore or something similar to capture the differences in behavior. It seems a bit messy currently.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Agreed, seems there are indeed some implementation details that differ between them and need to be special handled. It is worth considering to put these different details into Iceberg's own subclass.
|
Thanks for the release note! Nit of formatting suggestion: |
366408c to
4a0b64d
Compare
|
Thanks @steveburnett, fixed. Please take a look when available. |
agrawalreetika
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@hantangwangd Can we add some tests in iceberg which tests these newly added code lines?
...-hive-metastore/src/main/java/com/facebook/presto/hive/metastore/file/FileHiveMetastore.java
Outdated
Show resolved
Hide resolved
...-hive-metastore/src/main/java/com/facebook/presto/hive/metastore/file/FileHiveMetastore.java
Outdated
Show resolved
Hide resolved
...-hive-metastore/src/main/java/com/facebook/presto/hive/metastore/file/FileHiveMetastore.java
Outdated
Show resolved
Hide resolved
4a0b64d to
e3fa5dc
Compare
e3fa5dc to
7330926
Compare
I constructed a test environment based on a customized |
Looks good, thanks! |
8bfd938
7330926 to
8bfd938
Compare
|
New release note guidelines. Please remove the manual PR link in the following format from the release note entries for this PR. I have updated the Release Notes Guidelines to remove the examples of manually adding the PR link. |
|
@steveburnett Thanks for the reminder, fixed! |
|
This is simply rebased to the newest commit list, please take a look when available, thanks a lot! @ZacBlanco @agrawalreetika @tdcmeehan |
ZacBlanco
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
just some minor things
...eberg/src/test/java/com/facebook/presto/iceberg/hive/TestRenameTableOnFragileFileSystem.java
Outdated
Show resolved
Hide resolved
...eberg/src/test/java/com/facebook/presto/iceberg/hive/TestRenameTableOnFragileFileSystem.java
Outdated
Show resolved
Hide resolved
...eberg/src/test/java/com/facebook/presto/iceberg/hive/TestRenameTableOnFragileFileSystem.java
Outdated
Show resolved
Hide resolved
...eberg/src/test/java/com/facebook/presto/iceberg/hive/TestRenameTableOnFragileFileSystem.java
Outdated
Show resolved
Hide resolved
| metadataFileSystem.delete(newTablePermissionDir, true); | ||
| } | ||
| catch (IOException e) { | ||
| // ignore |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
maybe log a warning here with the error?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sure, done!
...-hive-metastore/src/main/java/com/facebook/presto/hive/metastore/file/FileHiveMetastore.java
Outdated
Show resolved
Hide resolved
| @Override | ||
| public boolean mkdirs(Path f, FsPermission permission) throws IOException | ||
| { | ||
| if (this.failSignal.get() == FailSignal.COPY) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why is the signal for mkdirs COPY? Maybe just rename to MKDIRS?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The mkdirs operation is a step of the COPY operation, we want to simulate the behavior of failure during the COPY process. But I think it's fine to use MKDIRS to reduce the confusion, fixed!
| if (!metadataFileSystem.rename(originalMetadataDirectory, newMetadataDirectory)) { | ||
| throw new PrestoException(HIVE_METASTORE_ERROR, | ||
| format("Could not rename table, because of fail to rename directory %s to %s", originalMetadataDirectory, newMetadataDirectory)); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we extract this rename in a utility method and use that instead here and above?
| createFile(fileSystem, new Path(originSchemaMetadataPath), DATABASE_CODEC.toBytes(databaseMetadata)); | ||
| createFile(fileSystem, new Path(newSchemaMetadataPath), DATABASE_CODEC.toBytes(databaseMetadata)); | ||
| createFile(fileSystem, new Path(originTableMetadataPath), TABLE_CODEC.toBytes(tableMetadata)); | ||
| createFile(fileSystem, new Path(originTablePermissionFilePath), new byte[128]); | ||
|
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let's extract this common code to a method use that instead in all the places where these file setup is done to reduce repetition
| assertFalse(fileSystem.exists(new Path(newTableMetadataPath))); | ||
| assertFalse(fileSystem.exists(new Path(newTablePermissionDirPath))); | ||
| assertFalse(fileSystem.exists(new Path(newTablePermissionFilePath))); | ||
| assertTrue(fileSystem.exists(new Path(originTableMetadataPath))); | ||
| assertTrue(fileSystem.exists(new Path(originTablePermissionDirPath))); | ||
| assertTrue(fileSystem.exists(new Path(originTablePermissionFilePath))); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Extract this common code in a method?
| } | ||
|
|
||
| @Test | ||
| public void testRenameTableFailCausedByRenameTableSchemaFile() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we can reduce the redundancy in different test methods by creating a new method with a common code in it and send different FailSignal as a parameter for different test cases?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good suggestion. I have refactor the code, extracted the common code logic into a base method testRenameTableWithFailSignalAndValidation. It accepts fail signal, customized rename logic and verification logic as parameters, and be invoked by all the test methods.
3110ae5 to
5c30649
Compare
5c30649 to
cf83835
Compare
|
Hi @ZacBlanco @agrawalreetika, the comments have all been addressed, please take a look when convenient, thanks! |
agrawalreetika
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
ZacBlanco
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM!
|
Hi @jaystarshot, can you please help take a final look at this PR when available? Thanks a lot! |
| } | ||
|
|
||
| private void renamePath(Path originalPath, Path targetPath, String errorMessage) | ||
| throws IOException |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Previously this code path seems to throwing a PrestoException in some places with a HIVE_METASTORE_ERROR
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is an extracted private method, the IOException thrown by it will always be caught by other methods and converted to a PrestoException with HIVEMETASTORE_ERROR as you mentioned.
| metadataFileSystem.delete(new Path(originalMetadataDirectory, PRESTO_PERMISSIONS_DIRECTORY_NAME), true); | ||
| } | ||
| catch (IOException e) { | ||
| // ignore |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Exception seems to be ignored here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is an intentional exception ignorance, as the deletion action here will not affect the entire rename behavior.
jaystarshot
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry I am not well versed with how the iceberg connector works but should there be iceberg specific code in the presto hive metastore
| metadataFileSystem.delete(newTablePermissionDir, true); | ||
| } | ||
| catch (IOException e) { | ||
| LOG.warn("Could not delete table permission directory: %s", newTablePermissionDir); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Same here, should we ignore exception here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The same as above.
@jaystarshot Thanks for your review. This is a good question. At present, all lake houses share the same HMS code, so that some Iceberg related code logic already existed in |
Description
This PR support renaming table behavior for iceberg tables on hive file catalog.
Motivation and Context
Support renaming table for Iceberg connector on as many catalog types as possible
Impact
Iceberg connector configured with hive file catalogs can now support renaming table
Test Plan
Contributor checklist
Release Notes