Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Hadoop Wiki" for change 
notification.

The "Hive/ViewDev" page has been changed by JohnSichi.
http://wiki.apache.org/hadoop/Hive/ViewDev?action=diff&rev1=7&rev2=8

--------------------------------------------------

  
  Note that besides table modifications, other operations such as CREATE OR 
REPLACE VIEW have similar issues (since views can reference other views).  The 
lenient approach provides a reasonable solution for the related issue of 
external tables whose schemas may be dynamic (not sure if we currently support 
this).
  
- '''Update 30-Dec-2009''':  Based on a design review meeting, we'll start with 
the lenient approach, without any support for marking objects invalid in the 
metastore, then follow up with strict support and possibly metastore support 
for tracking object validity.
+ '''Update 30-Dec-2009''':  Based on a design review meeting, we'll start with 
the lenient approach, without any support for marking objects invalid in the 
metastore, then if time allows, follow up with strict support and possibly 
metastore support for tracking object validity.
  
  == View Modification ==
  
@@ -119, +119 @@

  
  '''Update 30-Dec-2009''':  Based on feedback in JIRA, ORDER BY is important 
as forward-looking to materialized views.  LIMIT may be less important, but we 
should probably support it too for consistency.
  
+ == Underlying Partition Dependencies ==
+ 
+ '''Update 30-Dec-2009''':  Prasad pointed out that even without supporting 
materialized views, it may be necessary to provide users with metadata about 
data dependencies between views and underlying table partitions so that users 
can avoid seeing inconsistent results during the window when not all partitions 
have been refreshed with the latest data.  One option is to attempt to derive 
this information automatically (using an overconservative guess in cases where 
the dependency analysis can't be made smart enough); another is to allow view 
creators to declare the dependency rules in some fashion as part of the view 
definition.  Based on a design review meeting, we will probably go with the 
automatic analysis approach once dependency tracking is implemented.  The 
analysis will be performed on-demand, perhaps as part of describing the view or 
submitting a query job against it.  Until this becomes available, users may be 
able to do their own analysis either via empirical lineage tools or via 
view->table dependency tracking metadata once it is implemented.
+ 

Reply via email to