[teiid-dev] Exposing connector defined metadata to tooling.

[Ramesh Reddy]

Using JDBC is good idea. This all comes down to how you want to expose
the metadata. Do you want build another layer/API in the Admin API
and/or using the system tables to slurp the metadata or you would like
to use the JDBC database metadata retrieval. JDBC is readily available,
other one is little more work.

Ramesh..


On Fri, 2010-04-23 at 12:22 -0400, John Doyle wrote:
> I see how this makes sense in terms of reusing the current capabilities, but from a user interface design perspective I don't like the idea of fronting different sources with the JDBC importer.  Doing it this way put a bunch of JDBC specific concerns/metadata into the import process that probably don't apply.  I think it's a better UI approach to have a simpler generic importer that doesn't expose the JDBC metadata to the user, but exposes more simple relational concepts.
> 
> ~jd  
> 
> ----- "Van Halbert" <vhalbert at redhat.com> wrote:
> 
> > In regards to building an importer, for a client we built a jdbc
> > driver that provided the metadata from a spread sheet  to build the
> > models.     I think that approach could very easily be used for a text
> > file.
> >