db-torque-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Monroe <Greg.Mon...@dukece.com>
Subject RE: torque 4 site and further actions
Date Mon, 08 Mar 2010 15:56:35 GMT
Take a three day weekend and....lol  (BTW - Big THANKS Thomas F for doing
all this...)

> The Torque 4 site is deployed at
> http://db.apache.org/torque/releases/torque-4.0/index.html
> It is not yet linked from the main Torque site, my plan is to do that on
> monday. So if you find any errors there, there is still time to correct
> them.

Haven't had time to review.. will do it later today.

> The test project is now running for the following databases:
> - postgresql
> - oracle
> - mysql
> - mssql
> with id method "native". There are some remaining problems with the id
> methid "idbroker", but I am confident I 'll have it sorted out in the
> near future.
> I also still need to figure out how to best treat the conditional manager
> and bean tests, but I'll document it on the site once this is done.
> further actions:

Once the dust settles, I may blow the dust off some test project mods I was 
playing with during the 3.3 release.  I was basically trying to simplify
running the test project against the common variations of build options
in a standardized way. See:


> - The external-schema support is missing, I hope I get at it in the near
> future.  However, I'm curious to know what it is good for. Does anybody
> have a use case ?

I use this as follows:

I have a core project which has its own DB schema which generates it's
own set of Torque packages.

The core project has several "plug ins" that interact with various 3rd 
party applications.  Each "plug in" has its own Torque schema that 
models the 3rd party DB plus any "interface" tables that map core to 
plug-in. I separate the 3rd party DB from my interface tables into
their own XML files.  Each of these are generated into their own 

The plug-in interface tables use keys from the core tables and the 3rd
party schema.  So, I use the external-schema to include them so it can 
use the key columns required.

I also use it with a master test project that builds the entire system
with all plug-ins (e.g. master schema includes all subschema).

This allows me to easily maintain changes in 3rd party code, interface
code and the core.   

> - As the tool for code generator is called generator, and there is an
> interface inside it for a class that produces text for the output which
> is also called generator , my personal opinion is that the name of one
> object should be changed to avoid confusion. As the name for the module 
> is quite old, the interface name should be changed, and the references to 
> it in the configuration. I'm still not sure which name to use. possible 
> candidates that come to my mind are TextWriter, TextCreator, OutputWriter,
> OutputCreator... any recommendations or other ideas ?

+1 on removing overloaded terminology.. not sure what it should be 
called but in this age of auto completing editors... don't be afraid of 
long names like GeneratorInterface.  FWIW - In naming stuff, I tend to 
try to distill down what the class will be responsible for.  I generally 
start with trying to get first Javadoc line as clear as possible then
go from there.

> - Currently the maven2 generator plugin is just a frontend for the
> current code generator. However, there are a few goals from the old 
> generator which should probably remain like jdbc2xml. I'd like to 
> investigate whether we want to provide the functionality or if we can 
> use ddlutils for some tasks.

More on this in a separate e-mail... FWIW - When I've pushed DDLUtils
in the past, I was thinking more about using it's API to support 
Torque's targets rather than dropping them.  It would be less of a
"shock" to current users.

> - Ant integration for the generator is still missing. This should not be
> a big problem, but needs to be done. In my opinion, this should go into a
> separate small package torque-ant-tools

Sound good... IMHO - we can't release a Torque package without ant support.

> - Do we still want to support java 1.4 in Torque 4 runtime & generated
> classes ?

+1 on moving to 1.5.  This would probably simplify the templates greatly.

> - Which databases do we want to support in Torque 4 ? I believe e.g. the
> claim that we support db2 in Torque 3.3 is just nonsense, we do not have
> a driver for any recent db2 database. So my suggestion is to concentrate 
> on the databases that we really support and which we test with each release.
> A suggestion for this set would be mysql, postgresql, mssql, oracle, derby
> and hsqldb. What do you think ?

I agree on focusing/testing on these popular dbs.. but I don't think we
should drop "db2" from the docs.  Perhaps we could have a "testing and
supported" DB list and a "legacy " list (e.g. db2, Sybase, and MS Access
come to mind).  These could have a note that we'd welcome someone who
wants to fully support one of these.  The idea is to focus but still
show flexibility.

DukeCE Privacy Statement:
Please be advised that this e-mail and any files transmitted with
it are confidential communication or may otherwise be privileged or
confidential and are intended solely for the individual or entity
to whom they are addressed. If you are not the intended recipient
you may not rely on the contents of this email or any attachments,
and we ask that you please not read, copy or retransmit this
communication, but reply to the sender and destroy the email, its
contents, and all copies thereof immediately. Any unauthorized
dissemination, distribution or copying of this communication is
strictly prohibited.

To unsubscribe, e-mail: torque-dev-unsubscribe@db.apache.org
For additional commands, e-mail: torque-dev-help@db.apache.org

View raw message