Is there any chance we can make the Peer classes non-static?
Currently it's hard/impossible to override/extend these without making
generator changes. Perhaps have some form of central "registry" to
hold these classes so that they can be globally looked up but
also replaced/extended if desired.
The other suggestions are all very good - especially removing village.
Thanks
Joe
On 29/11/06, Thomas Fischer <[EMAIL PROTECTED]> wrote:
Now that the first Torque RC is outit is time to think about what we'd
like
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
criteria)
- 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
query.
- 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 ?
Thomas
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
