commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Craig R. McClanahan" <>
Subject Re: [sql] Refactor JDBCTransformTast?
Date Fri, 18 Oct 2002 19:52:39 GMT

On Fri, 18 Oct 2002 wrote:

> Date: Fri, 18 Oct 2002 15:40:08 -0400
> From:
> Reply-To: Jakarta Commons Developers List <>
> To:
> Subject: [sql] Refactor JDBCTransformTast?
> Hi all,
> I am looking at leveraging the JDBC -> xml capabilties of the SQL package.
> I looked at the JDBCTransformTask, and it does what I need, but I would like
> to output the information in a different format (what DBForms uses
> Should I refactor the JDBCTransformTask into two classes, one with all the
> getColumns(), getTables() etc, and one that outputs the data in Torque
> format?  And then use the refactored DatabaseMetaDataBuilder (?) and my own
> DbFormsJDBCTransform to output the metadata in my own format?
> I don't want to refactor the code if it isn't something that would be
> commited.

Interesting ... I was looking at the same class for the same reason
recently.  My thought was to split the JDBC-->XML functionality into two
pieces:  JDBC-->Internal graph of objects starting with
o.a.c.s.model.Database, and Object Graph->XML (which already exists via
DatabaseWriter).  That way, a tool or app that wanted to introspect a set
of database metadata, and then use it directly, could do so without having
to do it in two steps.

One question I had when looking at this, though ... the data model
represented in the XML document format doesn't totally match that
represented in the o.a.c.s.model package classes.  Shouldn't it?

> Eric Pugh

Craig McClanahan

To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message