11:22 a.m.
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.
11:32 a.m.
New subject: 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.
>
2:21 p.m.
New subject: Exposing connector defined metadata to tooling.
There are two sides to an importer:
1. UI stuff specific to the source type for configuring source specific import settings
(type mappings, delimiters, ...), the source connection, etc.
2. UI stuff to determine what to import
It doesn't matter if everything looks like "JDBC" for step 2, since
you've already determined what are tables/relationships, procedures, etc. It
doesn't have to be exposed to the user as JDBC DatabaseMetaData per se, but would lend
itself to a consistent UI.
But we can't forget that step 1 is actually the more complicated part. Especially as
John was mentioning with things like text files.
----- Original Message -----
From: "Ramesh Reddy" <rareddy(a)redhat.com>
To: "John Doyle" <jdoyle(a)redhat.com>
Cc: "teiid-dev" <teiid-dev(a)lists.jboss.org>, "Van Halbert"
<vhalbert(a)redhat.com>
Sent: Friday, April 23, 2010 11:32:56 AM GMT -06:00 US/Canada Central
Subject: 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.
>
_______________________________________________
teiid-dev mailing list
teiid-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/teiid-dev
3:08 a.m.
New subject: Exposing connector defined metadata to tooling.
On Fri, 2010-04-23 at 15:21 -0400, Steven Hawkins wrote:
1. UI stuff specific to the source type for configuring source
specific import settings (type mappings, delimiters, ...), the source
connection, etc.
2. UI stuff to determine what to import
To begin with, if Teiid has importer plugin with 2, and for 1 have below
a. simple basic UI configurable based on supplied properties
b. has extensible plugin based configuration
it would be help. For (a) I am thinking, if we provide a configuration
file for each source type, it should create a new importer. This screen
would contain properties such as in these
https://community.jboss.org/docs/DOC-15058 in JDBC and Text connectors.
Obviously, for this somebody needs to come with a simple DSL to drive
the UI that drives the configuration file.
Ramesh..
5380
days inactive
5381
days old
3 comments
3 participants
participants (3)
-
John Doyle -
Ramesh Reddy -
Steven Hawkins