3 Replies Latest reply on Sep 5, 2013 2:45 PM by Steven Hawkins

    Runtime support for CREATE VIEW

    Mark Addleman Master

      I'm a bit surprised this hasn't come up in our conversations before but I couldn't find a reference to it in the forum or jira:  What do you think of providing runtime CREATE VIEW behavior?


      As I understand it, the cost of implementing runtime DDL commands is about synchronizing the VDB in a cluster.  What about writing an implementation of MetadataRepository backed by Infinispan and thus (somewhat) automatically leveraging its cluster-wide memory space?  I'm pretty sure supporting all VDB constructs is more difficult than just sharing a common metadata repository but, very naively, it seems that views are the simplest.

        • 1. Re: Runtime support for CREATE VIEW
          Ramesh Reddy Master



          Having a persistent operational metadata repository is one, then using that operational store for all the metadata looks ups is another hurdle. As you know currently metadata store is built only during the deploy time and thus it is more static in nature. It is not just adding definition of view to store is concern, it is more of how addition/modification of this view affects other views that may be dependent upon this view, thus requiring the validation of other views and cascading nature of it. Right now there is no intelligent way to walk the dependency graph of view definitions such that it will not require whole VDB re-validation. 


          This is certainly a goal to achieve and is on Teiid road map but it may not come until 9.x cycle.



          • 2. Re: Runtime support for CREATE VIEW
            Mark Addleman Master

            Ah.  Thanks for the clarification, Ramesh.  I was naively assuming that views are only resolved during the planning stage so any dependency checking would occur at that time.


            • 3. Re: Runtime support for CREATE VIEW
              Steven Hawkins Master

              Create view/table/procedure is the next logical runtime update for us to support.  Just to clarify adding a view/table/procedure is only an issue when there are unqualified references in other view/procedure definitions such that the new view may introduce an ambiguity.  Ideally we would keep a fully qualified form of the metadata once resolved.  At the worst we'd just let the object be added, and then on the next vdb start the metadata validation would catch a problem.


              The crux of creates (beyond the update in the metadata repository) is transactionality, adding another cluster event, updating the metadata classes accordingly (for safe concurrent traversal), and updating internal materialization (for pg metadata queries) that is based upon the system tables. Dropping a view/table/procedure is what requires more dependency analysis than we currently track.