[
https://issues.apache.org/jira/browse/HIVE-27473?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17940940#comment-17940940
]
Seonggon Namgung commented on HIVE-27473:
-----------------------------------------
If I understand correctly, HIVE-28879 proposes introducing a new field in
Hive-Catalog (the internal concept in Hive, e.g., api.Catalog) to specify the
type of Data-Catalog (such as HMS, Glue Data Catalog, Iceberg REST Catalog) it
belongs to. This would require Hive to support multiple Data-Catalogs at
runtime, either in HS2 or HMS. I believe HS2 is the more appropriate place, as
relying on HMS would defeat the purpose of supporting external Data-Catalogs.
Based on this understanding, HIVE-28879 appears to be an extension of
HIVE-12679 (particularly given that HIVE-21059 and HIVE-12679 seem to implement
the same feature). While I still need to study HIVE-28879 further, as well as
understand the meaning of "Catalog" in Hive, it seems that HIVE-28879 faces the
same core issues discussed in HIVE-12679. For that reason, I believe we need to
decide between Option 1 or 2 in your design document before proceeding with the
implementation of HIVE-28879.
I also had two quick thoughts after reviewing the related JIRAs and code:
1. It seems Hive-Catalog is still in an early stage of development. HIVE-18685,
which introduced Hive-Catalog, has several open subtasks, and there are some
comments highlighting the ambiguity around the notion of the "current catalog"
(cf. SessionHiveMetaStore#drop_table_with_environment_context,
IMetaStoreClient#dropTable). So, I think we need to be more cautious when
dealing with Hive-Catalog.
2. I believe HIVE-28879 might be implementable using the approach I proposed in
my sample code for HIVE-27473. This could be done by adding a sixth layer
between the Cache and Thrift layers, which could also be a possible place to
implement HIVE-12679. Unfortunately, I haven't had enough time to work on
HIVE-27473 this week, but I might have enough time next week to resume that
work, and I would be able to consider HIVE-28879 as a potential feature when
organizing the design document.
> Make SessionHiveMetaStoreClient and HiveMetaStoreClientWithLocalCache
> composable
> --------------------------------------------------------------------------------
>
> Key: HIVE-27473
> URL: https://issues.apache.org/jira/browse/HIVE-27473
> Project: Hive
> Issue Type: Improvement
> Components: Hive
> Affects Versions: 4.0.0-alpha-2
> Reporter: Shohei Okumiya
> Assignee: Seonggon Namgung
> Priority: Major
>
> Currently, we implement the two classes using inheritance. It assumes we
> always use a single implementation of IMetaStoreClient.
> Some community members have been willing to make IMetaStoreClient pluggable
> as proposed in HIVE-12679. Considering the use case, we should provide the
> additional traits with composition over inheritance.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)