[teiid-dev] vdb.xml improvements

[Steven Hawkins]

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 at lists.jboss.org
> >>> https://lists.jboss.org/mailman/listinfo/teiid-dev
> >>>
> >>
>