[teiid-dev] vdb.xml improvements

[Ramesh Reddy]

I am fine with us making the below suggested usability changes, as we
have long runway on 8.x series. Model -> Schema renaming was the one I
am hesitant about.  Modeshape being operational store is separate issue,
that we can tackle when Teiid has completely DDL based metadata
definitions, or in the way to have such operational semantics.

I will log JIRA.

Ramesh..

On 03/25/2013 10:45 AM, Steven Hawkins wrote:
> 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
>>>>>
>>>>
>>