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.