<html><head><style type='text/css'>p { margin: 0; }</style></head><body><div style='font-family: verdana,helvetica,sans-serif; font-size: 12pt; color: #000000'>1) Our 8.1 release will include a new Teiid DDL importer that can deploy data sources (connections) along with a temporary dynamic VDB in order to ask Teiid Admin for the deployed VDB's DDL (aka schema).<br><br>2) Part of this feature includes adding a Teiid Dialect DDL Parser/Sequencer in Modeshape. Designer will use this parser to obtain a relational tree we can turn into EMF objects... similar to JDBC Metadata through that importer.<br><br>3) Our original plan was to throw this DDL away once the import is finished. Though it wouldn't take much to let users save these DDL/schema to a workspace *.ddl file.<br><br>4) Beyond that, if it would benefit users to have "Dynamic VDB" editing capability in Designer, we could put that in our future plans<br><br>5) lastly, adding DDL files to VDB archive in place of "model metadata" entries in vdb.xml makes sense and is also doable.<br><br>Barry<br><br><hr id="zwchr"><blockquote style="border-left:2px solid rgb(16, 16, 255);margin-left:5px;padding-left:5px;color:#000;font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt;"><b>From: </b>"Steven Hawkins" <shawkins@redhat.com><br><b>To: </b>"Ramesh Reddy" <rareddy@redhat.com><br><b>Cc: </b>"teiid-designer-dev" <teiid-designer-dev@lists.jboss.org>, "teiid-dev" <teiid-dev@lists.jboss.org><br><b>Sent: </b>Thursday, March 7, 2013 12:05:17 PM<br><b>Subject: </b>Re: [teiid-dev] vdb.xml improvements<br><br><br>----- Original Message -----<br>> I would rather see us go take upon the larges issues you listed like<br>> DDL<br>> based schema definition and leave the minor ones as is, as once DDL<br><br>I can see that viewpoint, but my thought is that we're making the vdb.xml a somewhat more visible artifact with product support for dynamic vdbs. Any steps toward easy of use / consistency would seem to help over the long run of the remaining 8.x line.<br><br>> feature implemented, it will change the vdb.xml anyway.<br><br>In a ddl only world all of our constructs need converted. CREATE FOREIGN DATA WRAPPER replaces translator declarations, GRANT statements for the permissions/roles, CREATE SCHEMA, etc. The question is to what degree does supporting xml declarations make our/Designer's life easier in the short/long run. Keeping the xml mostly saves us from writing more parsing hooks and until we allow these operations at runtime having a statement based mechansim for declaration is just a nice to have. So the question for the rest of 8.x is what if anything would be nice to declare in DDL rather than or in addition to xml?<br><br>On getting the DDL footprint down options include:<br> <br>- Keeping the zip concept and allowing the vdb.xml to reference a .ddl file in the vdb artifact<br> - In theory this would be implemented through the use of a built-in metadata repository<br><br>- begin work on the notion of a "live" modeshape metadata repository (this is mostly a separable effort)<br><br>- introduce notion of a deployable schema / .ddl artifact that can be referenced by the vdb.xml (this doesn't seem like the right approach). <br><br>Any other thoughts?<br><br>> <br>> On 03/05/2013 10:52 AM, Steven Hawkins wrote:<br>> > For 8.4 planning I'd like to solicit ideas about incremental<br>> > improvements we could make to our vdb.xml (of course we'd want to<br>> > make the changes backwards compatible). This would include minor<br>> > things like:<br>> > <br>> > - better property keys for example "UseConnectorMetadata" - which<br>> > isn't necessarily needed in its present form<br>> > - allowing the use of element text as an alternative to an<br>> > attribute for a property value<br>> > - terminology changes, such as model->schema<br>> > <br>> > To larger things like:<br>> > <br>> > - how/should we get the ddl memory footprint down<br>> > - future proof to allow for ddl based schema declarations<br>> > <br>> > Is there anything to add/remove from these? We'll rollup the<br>> > result into a JIRA.<br>> > <br>> > Thanks,<br>> > <br>> > Steve<br>> > _______________________________________________<br>> > teiid-dev mailing list<br>> > teiid-dev@lists.jboss.org<br>> > https://lists.jboss.org/mailman/listinfo/teiid-dev<br>> > <br>> <br>_______________________________________________<br>teiid-dev mailing list<br>teiid-dev@lists.jboss.org<br>https://lists.jboss.org/mailman/listinfo/teiid-dev<br></blockquote><br></div></body></html>