|
||||||||
|
This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira |
||||||||
|
||||||||
|
This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira |
||||||||
I wasn't thinking of something that general yet. I'm saying that to add a table/view/procedure to an existing schema is a straight-forward operation and all we need to do is allow for that update in the metadatarepository and to refresh the system materialized views (or to use an non-materialized option).
Alter/drop is more complicated since we do not track how view/tables/procedures are used to know if change is breaking.
To add a schema is nearly as straight-forward as adding a table/view/procedure except, as you point out, we keep that information in the vdb.xml. Here we could either continue to store the schema/model metadata in the vdb.xml ala the open shift vdb builder and in the spirit of the admin persistence changes we've made recently, or we could add additional metadatarepository constructs to represent schema/model additions.
Until we make further metadata refinements something like a full modifySchema wouldn't take affect until after a vdb restart.