[ https://issues.jboss.org/browse/TEIID-2578?page=com.atlassian.jira.plugin... ] Ramesh Reddy commented on TEIID-2578: ------------------------------------- To explain this further, Teiid currently has deployment based model, where a .vdb file deployment kicks off the creation of the VDB, and VDB file in an *external* file holds the metadata related to the VDB. This metadata is in read only mode. In this model, Teiid does *NOT* own metadata, it just reads from a file supplied, however who ever designed the metadata own it, they manage it external to the Teiid. So, inline edits are not possible. In the new system being proposed, there is a metadata repository, that Teiid keeps track of all the VDBs along with their metadata. Any changes you do using CREATE, ALTER and DROP happen to the metadata residing inside this metadata repository. When the changes are valid, a version of the metadata is deployed in Teiid as a VDB automatically. This is done because, in order to edit metadata using DDL Teiid needs to *OWN* the metadata to control it. The contention we have now is, should we go down this path? should we own both modes of operation, or keep to one. Since deployment is what we have done, it is impossible to get rid of this, without metadata repository, we can not give dynamic edibility of metadata. When I initially designed the system my recommendation is to have both modes of operation, with slightly modified/different capabilities in each mode. - In the deployment model, the source schema can be fetched during start of server or at the deployment time of VDB, in metadata mode, the schema can be fetched dynamically at any time, but it is static until it is *explicitly* refreshed by user, the restart of server does not affect it. - In the deployment model, user can use "import vdb" feature to import a child VDB into parent VDB. When a child VDB is modified independent of parent VDB, the changes are immediately reflected in the parent VDB. In repository model, the concept of import VDB where two or more independent VDBs working together does not exist, there is single VDB. For convenience purpose we provided DDL statement "import VDB", but this does one time copy of metadata from child VDB into parent VDB. After that, any changes to child will not be reflected automatically in the parent. - In the deployment model, the translators are registered at VDB scope, in the metadata repository model they are registered at global scope (same in embedded) - Management of metadata in cluster mode for *embedded* is not defined, current techniques are designed for working inside WildFly. So, this is one concern. - Repository model is much like any other RDBMS system like Oracle, Postgesql etc, where user with DDL can control the all aspects of the database. So it will be easier concept to explin to *new* users. I see pros/cons on both sides, IMO we may be able support both with some extra work, but with understanding of the above limitations. We can not make both work exactly same, and depending upon the client/user needs we can recommend one system over the other. Now we would like to know your opinions? -- This message was sent by Atlassian JIRA (v7.2.3#72005)