Dear Wiki user, You have subscribed to a wiki page or wiki category on "Db-torque Wiki" for change notification.
The following page has been changed by ThomasFischer: http://wiki.apache.org/db-torque/NextRelease The comment on the change is: Detailed descriptions of the Torque 4 plan ------------------------------------------------------------------------------ Consensus is to do the following things: - * Next main version should be 4.0. + * Next main version should be 4.0. There can be major changes in the version, but the 'look and feel' should change as little as possible. 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. - * Simplify the repository structure: No svn externals any more + * 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 not do so, this should not be problematic. - * Kick out village + * Kick out village. This would mean: create the sql to insert / update objects ourselves; do the Torque type / SQL type mapping of variables ourselves; change the way to create objects from jdbc result sets. - * Change the way to handle non-record-type queries (we used village for that until now) + * Change the way to handle non-record-type queries (we used village for that until now). * Criterias should not be modified any more inside queries. - * Disentangle Query description and SQL creation code. + * Disentangle Query description and SQL creation code. 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 the Criteria object only to hold query data and another object to hold update data. Criteria should not extend Hashtable any more. + * Use the Criteria object only to hold query data and another object to hold update data. Criteria should not extend Hashtable any more nor should 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) - * Use a column object to hold the column name in the runtime instead of Strings + * 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 remove the ambiguity which exists now that a String can be a value or a column name. - * Support views + * Support creation of database views in the generator and access to database views in the runtime. * Use a custom velocity renderer to have nicely trimmed generated code. * Have a non-static version of Peer classes. Implementation details are under discussion. - * Evaluate whether ddlutils can be used for some generator tasks + * Evaluate whether ddlutils can be used for some generator tasks. Under discussion: - * Switch to Maven 2 as build system. + * Switch to Maven 2 as build system. Keep the maven 1 plugin. For building the Maven 1 plugin, we need to retain a skeleton Maven 1 build. - * Make the generator more generic. + * Make the generator more generic, i.e. change it to a general code generation tool. - * Support primitives in data objects + * Remove support for Primitives in data objects. Problematic: --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
