db-torque-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Joe Carter" <joe.car...@excite.com>
Subject Re: Torque 4.0 plan
Date Thu, 30 Nov 2006 10:58:25 GMT
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 <tfischer@apache.org> 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: torque-dev-unsubscribe@db.apache.org
> For additional commands, e-mail: torque-dev-help@db.apache.org
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message