InvisibleProgrammer commented on code in PR #6393:
URL: https://github.com/apache/hive/pull/6393#discussion_r3492478538
##########
common/src/java/org/apache/hadoop/hive/conf/HiveConf.java:
##########
@@ -2127,6 +2127,9 @@ public static enum ConfVars {
"If this is set to true the URI for auth will have the default
location masked with DEFAULT_TABLE_LOCATION"),
HIVE_ICEBERG_ALLOW_DATAFILES_IN_TABLE_LOCATION_ONLY("hive.iceberg.allow.datafiles.in.table.location.only",
false,
"If this is set to true, then all the data files being read should be
withing the table location"),
+
HIVE_ICEBERG_MATERIALIZEDVIEW_METADATA_LOCATION("hive.iceberg.materializedview.metadata.location",
"metastore",
Review Comment:
Honestly, I'm not sure what is the proper approach: As [HIVE-29578: Iceberg:
add support for logical
views](https://github.com/apache/hive/pull/6449#issue-4319494979) is merged, it
changes the whole picture:
This implementation uses a HiveConf setting.
That implementation uses a table property, `'view-format'='iceberg'`.
My problem is if we introduce the external keyword here and don't change the
existing view-format solution, we provide an inconsistent interface for the
users.
But I also don't think if the view-format table property is a proper
approach for materialized views: it works great until we stay within the Hive
engine. But what happens if we not?
How we will handle the case when the user creates a materialized view (or a
simple logical view) in Spark and we want to use it from Hive?
Should create external create the view if it doesn't exist and just fill the
Hive side of metadata if the view physically exists but Hive doesn't know about
it yet? Like how we do it with external tables?
Tagging @difin (as the author for Iceberg views) and @zabetak (as you are
on PTO now) here to get their opinion to get a consistent Hive behavior.
--
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]
