db-torque-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thomas Fischer <tfisc...@apache.org>
Subject Torque 4.0 plan
Date Wed, 29 Nov 2006 22:04:45 GMT
Now that the first Torque RC is outit is time to think about what we'd 
to do as next version. Personally, I'd like to propose the following:

- Next version should be 4.0. There can be major changes in the version, 
but the 'look and feel' should change as little as possibl. The idea 
would be that one can recompile one's Torque 3.2 or 3.3 project with the 
new Torque version and it should run with minor changes only.

- Switch to Maven 2 as build system. Maven 2 has much better multiproject 
support than Maven 1, so building will be easier.

- Simplify the repository structure: No svn externals any more. This would 
mean that all Torque components can only be released simultaneously, but 
as we have done so in the past anyway and compatibility problems would 
arise if we would'nt do so, this should not be problematic.

- Use Java 5 style generics and enumerations. One can use compiler 
settings to produce pre-1.5-executable class files.

- Kick out village. Village is bad. See the issue tracker for details. 
This would mean: create the sql to insert / update objects ourselves; do 
the Torque type / SQL type mapping of variables orselves; create objects 
directly from jdbc result sets.

- Use the Criteria object only to hold query data and another object to 
hold update data. Criteria should not extend Hashtable any more nor 
sahould it implement the map interface, cause query data is not a Map in 
any sense (e.g. the same column names can appear more than once in a 

- Criterias should not be modified any more inside queries. Of one needs 
modification, one can copy the criteria.

- Disentangle Query description and SQL creation code. In my eyes, it 
would be ideal to port the MVC paradigm to the SQL creation: The criteria 
is the model (what do I want to query), the view would cretae the SQL from 
the Query, and the controller would be the Peer class which executes the 

- Use a column object to hold the column name in the runtime instead of 
Strings. So one could remove all that distributed guesswork of "what is 
the table name, do we have a schema name or not" etc. This would also have 
the advantge that a String is clearly a value and not a column name.

- Make the generator more generic. I'd like to turn the generator into a 
generiy code generation tool, which can be used to create all sort of 
code, not just database access code. I'm currently working on a proposal.

   Any opinions ?


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

View raw message