0 Replies Latest reply on Jul 8, 2009 12:10 PM by jdoyle

    Metadata aware Connector API

    jdoyle

      I would like to hear some more of the thoughts around what the connector metadata API might look like (https://jira.jboss.org/jira/browse/TEIID-685).

      Here's some snips from an email thread JPAV and I had just to seed this conversation:

      *******************************
      On Jun 24, 2009, at 10:34 AM, John Doyle wrote:

      > Hey John,
      >
      > Don't know if you've seen the thread/Jira, but the Teiid team is
      > going to expose a metadata creation API to the connectors in 6.2. I
      > would like to push this towards a relational metadata API that could
      > have multiple implementations and be the only API for Teiid
      > relational metadata creation.
      >
      > It seems to me that we already have this API spread across several
      > plug-ins in designer, and that API could be modified to be the
      > eclipse-free metadata API that I envision.
      >
      > Do you have any thoughts on this?
      >
      > Can you tell me what plug-ins you think make up the existing API?
      > Obviouly c.m.metamodels.relational and
      > c.m.metamodels.transformation, are there others?
      >
      > ~john


      John,

      Jacobs, Hawkins, Ramesh, and I had a conversation about this a couple
      of weeks ago. I believe the metadata API available to the connectors
      currently is via MetadataRecords. The plan that Hawkins has is to
      take the 5 different metadata APIs and the respective implementations
      used by the server (that's right, 5...) and collapse them all into
      one. The API they're focusing on is already both Eclipse- and EMF-
      free. So, since it doesn't include EMF, that means the
      metamodels.relational and metamodels.transformation plug-ins you
      mention will *not* be part of that API. There are no plans to change
      the current Designer to remove either its dependency on EMF or VDB
      indexes, so there will be a compatibility layer in the server for a
      while to handle this. Once we have new tooling that deals with the
      new metadata API and (expected) SQL/MED representational format, we
      can finally cut the cord. Hawkins should be able to give you a
      detailed roadmap and schedule regarding the consolidation of metadata
      APIs and what the final API will look like.

      Thanks,

      JPAV
      *******************************

      Can I get some more detail on the plan? If there is an internal representation that's going to be exposed as an API, and you point me to it so I can take a look? I want to look at it with a view to standardizing all of the metadata I create across importer and connectors in future releases.

      ~jd