[
https://issues.apache.org/jira/browse/HIVE-972?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12793746#action_12793746
]
Prasad Chakka commented on HIVE-972:
------------------------------------
.. continuing discussion from hive-users@
1.
regarding metadata:
Are you saying that If a view is created on a partitioned table, it would
inherit the base table's partition columns as regular columns? (this will be a
common usecase when inserts into multiple partitions is supported) Even if we
are not supporting partitions right now, we need to think of the way we would
model metadata for partitioned views (not necessarily materialized views) so
that the changes made right now will not conflict too much with the future
changes.
I like the flat model as the inheritance model is too much of a overkill and
not really suited in this case. But I would rather put the view-def into
'StorageDescriptor' class. This would work well when partitioned views are
supported since 'Partition' class will inherit the view definition and the
future view schema can evolve while freezing the schema of partitions created
earlier.
The type of the 'view-def' column has to be a CLOB but I am not sure of
performance implications of having a CLOB column in a very large table. If it
is not advisable then it may be useful to put this CLOB (or view metadata in a
separate class and link to StorageDescriptor)
2.
> In SQL:200n, a view definition is supposed to be frozen at the time it is
> created, so that if the view is defined as select * from t, where t is a
> table with two columns a and b, then later requests to select * from the view
> should return just columns a and b, even if a new column c is later added to
> the table. This is implemented correctly by most DBMS products.
Do you know the reasoning behind this? This would make changing the base table
schema very hard and if I am not mistaken Facebook's base table schemas change
(mostly addition of new columns) more than ocasionally and it will be an
administrative nightmare to change all the dependent views. IMO, '*' should
represent all columns and if a view creator does not want to inherit changes to
base table schema then she can specify the exact columns instead of '*'.
3.
I like DependencyParticipant idea. We could use simple inheritance strategy
where the dependent table contains (table/view id, used_name_of_dependent_obj,
obj_id, obj_type)
4. +1 to Leniant Dependency Invalidation but there should be a command to
preview the invalid views.
> support views
> -------------
>
> Key: HIVE-972
> URL: https://issues.apache.org/jira/browse/HIVE-972
> Project: Hadoop Hive
> Issue Type: New Feature
> Components: Metastore, Query Processor
> Reporter: Namit Jain
> Assignee: John Sichi
>
> Hive currently does not support views.
> It would be a very nice feature to have.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
