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