[
https://issues.apache.org/jira/browse/HIVE-28373?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18061841#comment-18061841
]
yongzhi.shao edited comment on HIVE-28373 at 2/28/26 5:02 PM:
--------------------------------------------------------------
[~dkuzmenko]
Hello,testTwoClientCommitSameVersion #291
{code:java}
assertThat(expectedException.get()).isNotNull();
{code}
Theoretically, when two clients attempt to commit the same version, one of them
is bound to throw an exception under normal circumstances; therefore, the code
at line 291 must catch an exception. I have verified all test code locally.
However, I am uncertain whether cross-testcase interference might occur—for
instance, if a residual corrupted catalog file from a previous testcase ends up
affecting the next one.
But I think I've identified the root cause. In this version of the test case, I
used the Linux command-line {{mv -n}} command to simulate HDFS rename
semantics. This approach only works reliably on Linux systems; if the testing
platform is not Linux, it may encounter issues. This was actually due to my
lack of familiarity with the richer file operations available in the NIO
package at the time. The Linux command-line invocation can be replaced with
{{{}java.nio.file.Files.move(src, dst, CopyOption...){}}}. While this code may
still exhibit slightly different behavior on Windows compared to Linux, it
should work properly on Unix/macOS. I'll proceed to modify this section of the
code.
was (Author: lisoda):
[~dkuzmenko]
Hello,testTwoClientCommitSameVersion #291
{code}
assertThat(expectedException.get()).isNotNull();
{code}
Theoretically, when two clients attempt to commit the same version, one of them
is bound to throw an exception under normal circumstances; therefore, the code
at line 291 must catch an exception. I have verified all test code locally.
However, I am uncertain whether cross-testcase interference might occur—for
instance, if a residual corrupted catalog file from a previous testcase ends up
affecting the next one.
> Iceberg: Refactor the code of HadoopTableOptions
> ------------------------------------------------
>
> Key: HIVE-28373
> URL: https://issues.apache.org/jira/browse/HIVE-28373
> Project: Hive
> Issue Type: Improvement
> Components: Iceberg integration
> Affects Versions: 4.0.0
> Reporter: yongzhi.shao
> Assignee: yongzhi.shao
> Priority: Major
> Labels: pull-request-available
> Fix For: 4.1.0
>
>
> Since there are a lot of problems with hadoop_catalog, we submitted the
> following PR to the iceberg community:
> [core:Refactor the code of HadoopTableOptions by BsoBird · Pull Request
> #10623 · apache/iceberg
> (github.com)|https://github.com/apache/iceberg/pull/10623]
> With this PR, we can implement atomic operations based on hadoopcatalog.
> But this PR is not accepted by the iceberg community.And it seems that the
> iceberg community is trying to remove support for hadoopcatalog(only for
> testing).
> Since hive itself supports a number of features based on the hadoop_catalog
> table, can we merge this patch in hive?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
