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/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). 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). BTW: Hibernate got this surprisingly well worked out. We can learn from them here. Regards Henning -- Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH [EMAIL PROTECTED] +49 9131 50 654 0 http://www.intermeta.de/ 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
