commons-dev mailing list archives

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


On Fri, 18 Oct 2002 EPugh@upstate.com wrote:

> Date: Fri, 18 Oct 2002 15:40:08 -0400
> From: EPugh@upstate.com
> Reply-To: Jakarta Commons Developers List <commons-dev@jakarta.apache.org>
> To: commons-dev@jakarta.apache.org
> 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
> www.dbforms.org).
>
> 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:   <mailto:commons-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:commons-dev-help@jakarta.apache.org>


Mime
View raw message