[
https://issues.apache.org/jira/browse/HIVE-972?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12793711#action_12793711
]
Ashish Thusoo commented on HIVE-972:
------------------------------------
Pretty comprehensive writeup :) Here are my comments:
1. It may be better to just go with a flat model to keep things simple. Also
whenever we do materialized views in future you do have an object that is part
table and part view and you may just need the flat model anyway at that point.
The primary reason though to go with the flat model would be simplicity and
less severe schema migration of the metastore schema.
2. For dependency tracking there is already code in hive that uses pre
execution hooks to track lineage. That could easily be used to extract view
dependencies (table level dependencies) when you create the view metadata.
Raghu also had done some work on column lineage and perhaps that can be used to
capture column lineage.
I think for the first cut we should just go with table dependencies and leave
column stuff for later. We should have the lenient dependency invalidation
scheme (perhaps for both drops and alters) because at least that way users can
inspect view definitions and then fix them later. Accordingly then we would
need a flag to mark an invalidated view and maybe some way of looking at that
list. I think we can punt the cascade option for now as that seems to be an
optimization in the user workflow and could be added later. Thoughts? The
restrict though is probably more useful. We could have that be the default in
the strict mode (Hive has a strict mode which disallows queries on partitioned
tables in case a where clause on the partition column was not specified),
Not sure on what we should do about temporary functions but if we use views to
transform our internal logs to another schema (nectar imps -> context) then we
may need it.
3. I am not sure if supporting limit is important but I can see good use of
order by when we do materialized views. The sorted property could be helpful
there and would be good to capture. We already capture those for tables.
4. I think fast path should work seemlessly, once the fast path with filters is
done, no?
5. I think we can punt view modification for now if we support ways of
inspecting the view sql for folks.
> 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.
