Re: [teiid-dev] Exposing connector defined metadata to tooling.
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(a)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.
>