I would rather see us go take upon the larges issues you listed like DDL based schema definition and leave the minor ones as is, as once DDL

feature implemented, it will change the vdb.xml anyway.

On 03/05/2013 10:52 AM, Steven Hawkins wrote: > For 8.4 planning I'd like to solicit ideas about incremental > improvements we could make to our vdb.xml (of course we'd want to > make the changes backwards compatible). This would include minor > things like: > > - better property keys for example "UseConnectorMetadata" - which > isn't necessarily needed in its present form > - allowing the use of element text as an alternative to an > attribute for a property value > - terminology changes, such as model->schema > > To larger things like: > > - how/should we get the ddl memory footprint down > - future proof to allow for ddl based schema declarations > > Is there anything to add/remove from these? We'll rollup the > result into a JIRA. > > Thanks, > > Steve > _______________________________________________ > teiid-dev mailing list > teiid-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/teiid-dev >

----- Original Message ----- > I would rather see us go take upon the larges issues you listed like > DDL > based schema definition and leave the minor ones as is, as once DDL 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.

> feature implemented, it will change the vdb.xml anyway. 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? From Designer perspective, they are not doing any work with DDL based

On getting the DDL footprint down options include:

- Keeping the zip concept and allowing the vdb.xml to reference a .ddl file in the vdb artifact - In theory this would be implemented through the use of a built-in metadata repository

- begin work on the notion of a "live" modeshape metadata repository (this is mostly a separable effort)

- introduce notion of a deployable schema / .ddl artifact that can be referenced by the vdb.xml (this doesn't seem like the right approach).

Any other thoughts? > > On 03/05/2013 10:52 AM, Steven Hawkins wrote: >> For 8.4 planning I'd like to solicit ideas about incremental >> improvements we could make to our vdb.xml (of course we'd want to >> make the changes backwards compatible). This would include minor >> things like: >> >> - better property keys for example "UseConnectorMetadata" - which >> isn't necessarily needed in its present form >> - allowing the use of element text as an alternative to an >> attribute for a property value >> - terminology changes, such as model->schema >> >> To larger things like: >> >> - how/should we get the ddl memory footprint down >> - future proof to allow for ddl based schema declarations >> >> Is there anything to add/remove from these? We'll rollup the >> result into a JIRA. >> >> Thanks, >> >> Steve >> _______________________________________________ >> teiid-dev mailing list >> teiid-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/teiid-dev >> >

To summarize where this left off from your and Barry's emails: > 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). > 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. > 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. > 5) lastly, adding DDL files to VDB archive in place of "model metadata" entries in vdb.xml makes sense and is also doable. Unless you are talking about modeling a dynamic vdb, it would make much more sense from our perspective if you kept the DDL - as they are the replacement for index files (which would be 5). > The property key names to more user friendly yes So things that could be more friendly: UseConnectorMetadata=true/cached - The true case could be removed entirely. The notion of metadata caching could be handled by a model property and should probably be more baked into the MetadataRepository facility (such as passing the cached metadata in for update). supports-multi-source-bindings=true/false - Since we have mostly removed the binding terminology, it would make more sense to call this just multi-source or multisource (which is consistent with the multisource.columnName and addColumn properties). We could also automatically infer it to be true when there are multiple sources listed for a single model (which is currently an error case without this property) so that it would only be needed if you wanted a single source to appear as if it were a multisource model. A JIRA is needed for a Modeshape or other operational metadata store that could even be shared with design time activities (similar to the way Composite operates). ----- Original Message ----- > > > On 03/07/2013 12:05 PM, Steven Hawkins wrote: >> >> ----- Original Message ----- >>> I would rather see us go take upon the larges issues you listed >>> like >>> DDL >>> based schema definition and leave the minor ones as is, as once >>> DDL >> >> 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. >> > The property key names to more user friendly yes, but changes like > model > -> schema does get us into ripple effects that does not provide any > additional functionality, but clarifies the intent better. > > >>> feature implemented, it will change the vdb.xml anyway. >> >> 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? >> > From Designer perspective, they are not doing any work with DDL based > VDBs in 8.x series. It is all pushed to their Komodo release. Any > work > we do should be for ease and feature support for Dynamic VDBs. > > May be we should really start a separate effort that is more based on > SQL/MED based DDL, that way when that is feature complete, we can > deprecate current vdb.xml model. I know this is more work, but gives > us > better segway into future. Deployer specific work should be minimal > compare to other parsing stuff. > >> On getting the DDL footprint down options include: >> > When you say DDL foot print down, you mean complete description of > VDB > just using DDL? > >> - Keeping the zip concept and allowing the vdb.xml to reference a >> .ddl file in the vdb artifact >> - In theory this would be implemented through the use of a >> built-in metadata repository >> > I would still also keep single file approach for simplicity along > with > zip versions. > >> - begin work on the notion of a "live" modeshape metadata >> repository (this is mostly a separable effort) >> > +1 We need some form of this in 8.x series. Yes, separate topic > >> - introduce notion of a deployable schema / .ddl artifact that can >> be referenced by the vdb.xml (this doesn't seem like the right >> approach). >> > You mean like each schema lives by its own, VDB concept groups them > together? > >> Any other thoughts? >> >>> >>> On 03/05/2013 10:52 AM, Steven Hawkins wrote: >>>> For 8.4 planning I'd like to solicit ideas about incremental >>>> improvements we could make to our vdb.xml (of course we'd want to >>>> make the changes backwards compatible). This would include minor >>>> things like: >>>> >>>> - better property keys for example "UseConnectorMetadata" - which >>>> isn't necessarily needed in its present form >>>> - allowing the use of element text as an alternative to an >>>> attribute for a property value >>>> - terminology changes, such as model->schema >>>> >>>> To larger things like: >>>> >>>> - how/should we get the ddl memory footprint down >>>> - future proof to allow for ddl based schema declarations >>>> >>>> Is there anything to add/remove from these? We'll rollup the >>>> result into a JIRA. >>>> >>>> Thanks, >>>> >>>> Steve >>>> _______________________________________________ >>>> teiid-dev mailing list >>>> teiid-dev(a)lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/teiid-dev >>>> >>> >