[teiid-dev] Connector Based Metadata

[John Doyle]

----- "Ramesh Reddy" <rareddy at redhat.com> wrote:

> I completely agree with your other points. Yes, these both modes are
> different and provide different levels integration to the user. We
> have
> to pursue both modes.
> 
> On Wed, 2009-06-17 at 13:42 -0400, Ken Johnson wrote:
> > > What we want to do now is define the runtime model we need for
> the
> > > engine, then whatever the persistent form may that be DDL or
> SQL/MED
> > or
> > > XML will defined in coming releases, that produces this runtime
> > model.
> > >   
> > I'm a bit unclear here.  There's a need to define the runtime model
> > we 
> > need for the engine?
> The current metadata language object definitions we have is the
> contract
> between the index/xmi/vdb files to Teiid Engine. Currently we do not
> define a metadata model that can be used by the connector (I am
> talking
> about metadata consumption by the engine from connector, not how
> engine
> communicates with connector). 
> 
> We need some APIs in the Connector API that we need to either define
> or
> elevate from the metadata module, so that connectors can define their
> metadata in a consistent manner across all connectors. Then it is up
> to
> Connector developer to define its persistent from metadata of whether
> it
> is ad-hoc program or DDL or XMI files or Custom Script (ex:text
> connector).
> 

What I would like to see come out of this is THE API that is used to create relational metadata for Teiid.  It should be complete for our entire relational model, and it should be extensible like the current model.  It could then be implemented and exposed in all of the places where we will allow metadata to be provided (whereever that may be).  Users would then have two options for supplying metadata, the serialized form that we decided upon, and the API.

A Teiid user who decided to integrate their source with Teiid could then create the code that maps their source metadata to our relational object model once, and then plug that into the place where they want to define metadata.  Maybe it's the connector, maybe it's an importer in Designer, maybe it's the shell, maybe all of them, we don't really know what going to be available.

In the places where we implement this API, we're smart about what we do with it.  The Teiid connector implementation could be free to ignore any metadata it doesn't need, the Designer impl writes it all to the serialized form.  Users don't really care about XMI or index files, they want simplicity and ease, and we can give it to them.  

 
> The example SteveH keep using us akin to JDBC Metadata, where you can
> inquire JDBC source about its metadata data, where it provides the
> metadata in resultset, here I am talking about a object model, that
> is
> the difference.
> 
> Ramesh..