Henning Schmiedehausen wrote:
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 centricand 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/OracleBuilder.java). 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 http://www.mail-archive.com/[email protected]/msg13893.html) 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).
I agree with a lot of your points, and disagree with a few others, however there are two things that made me start this vote now:
* In OJB, we only need SQL generation, and Torque is not exactly easy to use: the build script is complicated for a user (though it got better since 3.0), and Torque cannot be easily used at runtime, which is something that works really well in commons-sql. Also, AFAIK Torque cannot deal with existing databases (alter table).
However, having commons-sql in jakarta instead of db means more hassle for us. In db, all OJB (and Torque) committers could easily have commit rights to the moved commons-sql.
* Of course there is a lot of overlap with Torque, but a strategic discussion will take another half of a year or more before (if) anything gets done (and even more when putting commons-sql into incubation). I prefer the pragmatic approach and start working on commons-sql now, so it can be used by OJB and others.
That being said, I'd really like a merge of functionality with the corresponding Torque part, but that should not be a big-bang action, I think (and probably not a topic for this vote either). I'd like to discuss this off-topic though, if you want ?!
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 representation).
I'm not so sure about that, actually. A one-size-fits-all XML representation can easily get too complicated to be handable. Also, the metamodel of OJB for instance can easily transformed on-the-fly to a database schema (with little extra database-specific info). And in the end, an end-user does not want to have to deal with XML files anyway, but rather use XDoclet/Annotations or something even more automatic, I think.
regards, Tom
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
