hadoop-hive-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ashish Thusoo (JIRA)" <j...@apache.org>
Subject [jira] Commented: (HIVE-972) support views
Date Tue, 22 Dec 2009 18:26:29 GMT

    [ 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.

View raw message