h1. Development information The following changes are planned for the next release: * remove the old, deprecated and buggy \{ { \{ [ConnectionPool] \} } \}[done] * drop support for idMethod = sequence | autoincrement[done] * move all db specific stuff from the generated classes to the base classes (so you don't have to regenerate the modell for different dbs) * improve the generated ojb model * add scale attribute for columns[done] * add domain element to schema.xml (name, type, javaType, size, scale) ** the domains can be reused in any column ** this allows to map jdbc types to domains and solves the problem with definitions like BIGINT = NUMBER (20, 0) * add platform package to replace db.prop files (inheritence is your friend ;) * backport sql generation for the generator from commons-sql (inheritence is your friend ;) ---- Further Suggestions: * Update the handling of [PostgreSQL] sequences for version 7.3 (see: [TorqueProjectPages]/PostgreSQLFAQ) ** If no id-method-parameter elements are declared then the sequence should be named table_column_seq and the sequence does not need to be explicitly created or dropped. ** Perhaps use the current behaviour if id-method-parameter elements *are* declared so as to cater for [PostgreSQL] versions prior to 7.3. * Correctly generate index and unique constraint names for [PostgreSQL] (see: [TorqueProjectPages]/PostgreSQLFAQ) * Allow override of database name at generation time ** If specified the torque.database.name property should be user rather than name attribute of the database tag. This would make it much easier to handle multiple instances of an application on a single system, e.g. dev and test database instances being generated from a single schema. * Is it just me or are a number of the torque peoperties required to be declared outside of the file referred to in torque.contextProperties? Could the Torque Maven plugin read the properties in as well, making it so that project.properties need only define torque.contextProperties? This would make it much easier to handle multiple application instances built from the same environment (I run a number of filters across my properties file to customise it for the application/database instance I am generating before I execute the generator). * IMHO the Torque Maven plugin is very difficult to use due to varying versions of Maven and Torque (I had to actually hack the plugin to get things working). In particular I think we really need to support: ** Multiple versions of Torque. ** The ability to add further versions outside of the Maven release cycle. * Provide for an encoding attribute on the database element - to be used in create database statement for [PostgreSQL] (and presumably others). -- [ScottEade] 2003-10-09 * Modify the equals method in class [BaseObjet] to not only test primary key but objet class to. With torque 3.1, 2 Torque's objets of different class but with the same primary key are considered "equals". {noformat} {noformat} -- CL 2003-11-09 * Allow override of native limit on the size of result set size. (ie. make it possible to _not_ use a rownum query for Oracle, TRQS187) * Allow override of case insensitive sorting (using UPPER) on Strings (TRQS188)