Re: [teiid-designer-dev] [teiid-dev] vdb.xml improvements

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