[teiid-dev] Connector supplied metadata

Ramesh Reddy rareddy at redhat.com
Thu Jul 9 17:40:48 EDT 2009


Please see in-line..

On Thu, 2009-07-09 at 13:56 -0400, John Doyle wrote:
> 
> Maybe the problem is that it has not been sufficiently explained, at
> least not in a public forum.  

Based on my knowledge, we are not re-inventing the wheel here about
metadata.Let me see if I can explain..(Steve correct if any
mis-understandings on my part)

1) Previously what we had was "teiid-metadata" project defined a runtime
metadata object model, which was either generated from "eobjects" in the
designer or from index files from the VDB either in designer or teiid
runtime.

2) During the 6.0 time, these metadata runtime objects were re-factored
such that the notion of "eobjects" usage inside them was pushed into
Designer code, but still left way to inject them and build these
objects, to support preview and validation inside the Designer.

3) Teiid run-time never directly accessed these runtime objects, they
were always accessed through QMI (QueryMetadataInterface)

4) Now during 6.2, these metadata runtime objects are further elevated
into "connector-api" from "teiid-metadata" such that, a connector
developer (on choice) can define the metadata of his/her connector
dynamically using this metadata objects.

5) so, in effect engine can now get the metadata from connectors 

connector --> metadata --> QMI --> Consumed by Engine
designer --> eobjects --> metadata --> QMI --> Consumed by Engine
(preview)
designer --> index files(vdb) --> metadata --> QMI --> consumed by
Engine (runtime)

> I don't have any problem with implementing a new vision over several
> versions, which I suspect is what you're doing, but what's the
> vision.  
Yes, that is my understanding too. We may not able to fully convert all
the connectors to support this notion of metadata due to UI requirements
or  simply time/resource constrains.

> As far as I can tell from the public discussions and JIRAs, we are
> implementation a new API to be used in connector scope, and have an
> expectation that it will be grown into a full blown metadata API. 
Yes and no. I know we have set a lower expectations in JIRA as to what
at a minimum constitutes this feature. This not say to stop there.

>  That's backwards in my opinion.  We should be defining the best API
> we can based upon the universe of potential environments/clients that
> we envision for Teiid.  We can then implement over successive versions
> in different components, right away in connectors if that's the
> priority.
> 
If you think the current Designer based metadata model provides rich API
to define/model a source, then this would be no different. I know this
is not completely done yet, however I would encourage you take it for
spin and identify the any short comings, so that we can capture them and
fix them if time permitting. I agree that we need to put effort into
putting out mature API and we are!


Thanks

Ramesh..






More information about the teiid-dev mailing list