commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Henning Schmiedehausen <>
Subject Re: [Vote] Moving commons-sql to (repost)
Date Thu, 09 Dec 2004 17:29:06 GMT
On Thu, 2004-12-09 at 17:38, Thomas Dudziak wrote:
> Henning Schmiedehausen wrote:
> >>+1 Henning Schmiedehausen
> >>    
> >>
> >
> >This is for the principal vote to get commons-sql into the DB project.
> >Personally, I'd like to see commons-sql through incubation to get the
> >scope of the project defined. See my other mail on the commons-dev list.
> >  
> >
> I don't think that this would be a good idea, because I think its 
> purpose and place is clear (low-level db stuff like creating and 
> altering tables in a db-independent way). Of course the doc needs 
> rework, but this already an item on the to-do list.
> Btw, to what email do you refer (could you give a link to gmane/nagoya) ?

Yeah, but _what_ low-level db stuff?

commons-sql has already a lot of overlap with the torque-generator. And
torque-gen contains templates for
  - SQL generation (like commons-sql, but better (?) organized)
  - Torque Peer and Class Source generation
  - OJB Source generation 

In its current form, commons-sql is a step backwards from torque-gen,
because it _only_ does SQL code generation. It does it better than
torque-gen, no discussion here, but it does _only_ SQL code.

To elaborate this a bit further: The structure of a code generator like
commons-sql and torque-gen can (IMHO) be split into three parts:

- data model (currently just database/table/column. Where are other 
  parts of a database that are needed to model? Sequences? Views?)

- data output (set of templates that use the model to generate code)
  In commons-sql, there is only one set of templates around (in
  src/templates) and already there are function templates 
  (database-create, database-load, database-store) mixed up with
  control  or definition templates (db2, hsqldb and so on).

  How would one plug in another template set if the defaults do not
  suffice? How can I create custom templates and outputs? Can you split
  templates from the generator (e.g. load templates from class path or
  a give directory like torque-gen does)?

- A driver which controls the output generation. There is a rudimentary,
  Velocity only driver with Texen in the Velocity project

>>From these three parts, only the first two are really database centric
and only because they are hard coded into commons-sql. You could bundle
abstract representations of "data model" and "data output" together with
a generic driver and it would be a nice sub-project for Jakarta and then
bundle up a concrete implementation of the data model representing a
database with a set of templates for SQL and/or Source code generation
to become a part of DB. 

An example: One of the lessons _not_ learned from torque-gen is the db
type definition split into a textual representation (e.g. in
src/templates/oracle/9i/types.xml) and a code representation (e.g.
src/java/org/apache/commons/sql/builder/ You will
either have to juggle two files to contain similar information or get
out of sync. (BTW: about the internal structures: Well, I'd prefer to
move StringBuffers around instead of the whole print()/println() shebang
but that is just a matter of taste).
You do need an unified representation. We learned this in torque the
hard way. One file (preferably an XML file) which contains all the
information and a loader for programmatic representation.

Building yet another torque-generator (which could easily be split out
of the Torque project, because it contains almost no torque-runtime
related code) with just another technology (Jelly) that is not even
liked by the people who use it heavily and started commons-sql (e.g. see is
IMHO a bird that will not fly very far.

commons-sql must IMHO focus better. Should it be just the "single set of
beans" as mentioned at the top page of the project? Or an all enclosing
"XML -> SQL and back" mapper? Then you definitely will touch the realm
of other "XML -> something" mappers. And there are already a lot of
these out there. 

If you really insist on moving commons-sql to Apache DB in its current
state, then I would beg you to really think _more_ about the design of
your SQL generator than the parents of torque-gen did. torque-gen has
huge problems, trying to get stuff like "MySQL, version 4" and "MySQL,
version 3" done and struggles from a restrictive XML syntax (using the
short cuts for the ID generators was a _HUGE_ mistake). 

And in the end, you do want your XML data representations to contain
metadata that describes the O/R mapping when using things like Torque or
OJB. The worst possible solution would be our users having to maintain
_two_ XML files (one for SQL representation, one for the O/R

BTW: Hibernate got this surprisingly well worked out. We can learn from
them here.


Dipl.-Inf. (Univ.) Henning P. Schmiedehausen          INTERMETA GmbH        +49 9131 50 654 0
RedHat Certified Engineer -- Jakarta Turbine Development  -- hero for hire
   Linux, Java, perl, Solaris -- Consulting, Training, Development

"Fighting for one's political stand is an honorable action, but re-
 fusing to acknowledge that there might be weaknesses in one's
 position - in order to identify them so that they can be remedied -
 is a large enough problem with the Open Source movement that it
 deserves to be on this list of the top five problems."
                       --Michelle Levesque, "Fundamental Issues with
                                    Open Source Software Development"

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

View raw message