[DB Torque Wiki] Updated: NextRelease
Date: 2005-02-23T10:00:01 Editor: ThomasFischer Wiki: DB Torque Wiki Page: NextRelease URL: http://wiki.apache.org/db-torque/NextRelease typo Change Log: -- @@ -12,7 +12,7 @@ * 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 '''done''' + * add platform package to replace db.prop files - '''done''' * backport sql generation for the generator from commons-sql (inheritence is your friend ;-) == Further Suggestions == - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[DB Torque Wiki] Updated: NextRelease
Date: 2005-02-23T09:59:19 Editor: ThomasFischer Wiki: DB Torque Wiki Page: NextRelease URL: http://wiki.apache.org/db-torque/NextRelease Sorry, I misunderstood one of the further suggestions, undid some changes. Change Log: -- @@ -8,7 +8,7 @@ * improve the generated ojb model * add scale attribute for columns - '''done''' * Add support for outer joins - '''done''' - * Add some basic schema support, including override of database name at generation time - '''done''' + * Add some basic schema support at runtime and generate time - '''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) @@ -17,7 +17,8 @@ == Further Suggestions == - * 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. + * 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 properties 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). * Provide for an encoding attribute on the database element - to be used in create database statement for PostgreSQL (and presumably others). - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[DB Torque Wiki] Updated: NextRelease
Date: 2005-02-23T09:39:11 Editor: ThomasFischer Wiki: DB Torque Wiki Page: NextRelease URL: http://wiki.apache.org/db-torque/NextRelease no comment Change Log: -- @@ -2,25 +2,22 @@ == Planned for the next release == -Note that development for the next release in CVS can be found under the Branch TORQUE_3_1_BRANCH, but some of the items listed here have been done in HEAD. - - * remove the old, deprecated and buggy !ConnectionPool - '''done''' HEAD - * drop support for idMethod = sequence | autoincrement - '''done''' HEAD + * 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''' HEAD - * Add support for outer joins - '''done''' TORQUE_3_1_BRANCH - * Add some basic schema support - '''done''' TORQUE_3_1_BRANCH + * add scale attribute for columns - '''done''' + * Add support for outer joins - '''done''' + * Add some basic schema support, including override of database name at generation time - '''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 ;-) + * add platform package to replace db.prop files '''done''' * backport sql generation for the generator from commons-sql (inheritence is your friend ;-) == Further Suggestions == - * 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. + * 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 properties 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). * Provide for an encoding attribute on the database element - to be used in create database statement for PostgreSQL (and presumably others). - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[DB Torque Wiki] Updated: NextRelease
Date: 2004-12-21T04:33:09 Editor: ScottEade <[EMAIL PROTECTED]> Wiki: DB Torque Wiki Page: NextRelease URL: http://wiki.apache.org/db-torque/NextRelease no comment Change Log: -- @@ -2,15 +2,15 @@ == Planned for the next release == -Note that development for the next release in CVS can be found under the Branch TORQUE_3_1_BRANCH +Note that development for the next release in CVS can be found under the Branch TORQUE_3_1_BRANCH, but some of the items listed here have been done in HEAD. - * remove the old, deprecated and buggy !ConnectionPool - '''done''' - * drop support for idMethod = sequence | autoincrement - '''done''' + * remove the old, deprecated and buggy !ConnectionPool - '''done''' HEAD + * drop support for idMethod = sequence | autoincrement - '''done''' HEAD * 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 support for outer joins - '''done''' - * Add some basic schema support - '''done''' + * add scale attribute for columns - '''done''' HEAD + * Add support for outer joins - '''done''' TORQUE_3_1_BRANCH + * Add some basic schema support - '''done''' TORQUE_3_1_BRANCH * 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) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[DB Torque Wiki] Updated: NextRelease
Date: 2004-12-21T04:25:44 Editor: ThomasFischer <[EMAIL PROTECTED]> Wiki: DB Torque Wiki Page: NextRelease URL: http://wiki.apache.org/db-torque/NextRelease added Henning's basic schema support under "planned - done" section Change Log: -- @@ -10,6 +10,7 @@ * improve the generated ojb model * add scale attribute for columns - '''done''' * Add support for outer joins - '''done''' + * Add some basic schema support - '''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) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[DB Torque Wiki] Updated: NextRelease
Date: 2004-12-21T04:23:30 Editor: ThomasFischer <[EMAIL PROTECTED]> Wiki: DB Torque Wiki Page: NextRelease URL: http://wiki.apache.org/db-torque/NextRelease moved "support for outer joins" to Section "planned for the next release - done" Change Log: -- @@ -2,11 +2,14 @@ == Planned for the next release == +Note that development for the next release in CVS can be found under the Branch TORQUE_3_1_BRANCH + * 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 support for outer joins - '''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) @@ -34,17 +37,6 @@ * 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) - - - * Add support for outer joins - --- Don Vawter 2004-07-09 - - * Most definitely! Any data layer would not be complete with this feature. Patch TRQS219 takes care of this and should be integrated in the code base line. - We use it extensively and have had no issue with it! - --- Martin Goulet 2004-12-21 - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[DB Torque Wiki] Updated: NextRelease
Date: 2004-12-21T04:15:00 Editor: MartinGoulet <[EMAIL PROTECTED]> Wiki: DB Torque Wiki Page: NextRelease URL: http://wiki.apache.org/db-torque/NextRelease no comment Change Log: -- @@ -37,7 +37,14 @@ * Add support for outer joins + -- Don Vawter 2004-07-09 + + * Most definitely! Any data layer would not be complete with this feature. Patch TRQS219 takes care of this and should be integrated in the code base line. + We use it extensively and have had no issue with it! + +-- Martin Goulet 2004-12-21 + - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[DB Torque Wiki] Updated: NextRelease
Date: 2004-08-22T20:06:21 Editor: ScottEade <[EMAIL PROTECTED]> Wiki: DB Torque Wiki Page: NextRelease URL: http://wiki.apache.org/db-torque/NextRelease A couple of the listed items have been addressed in cvs even for 3.1.1 Change Log: -- @@ -15,19 +15,14 @@ == Further Suggestions == - * Update the handling of PostgreSQL sequences for version 7.3 (see: ["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: ["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 properties 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 + + * The jdbc target (torque:jdbc goal in Maven-speak) needs to generate the correct DDL SQL for PostgreSQL serial columns (see: ["PostgreSQLFAQ"]) -- ?ScottEade 2004-08-20 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[DB Torque Wiki] Updated: NextRelease
Date: 2004-08-05T02:40:50 Editor: DomenicoLoiacono <[EMAIL PROTECTED]> Wiki: DB Torque Wiki Page: NextRelease URL: http://wiki.apache.org/db-torque/NextRelease no comment Change Log: -- @@ -44,8 +44,10 @@ * Add support for outer joins -- Don Vawter 2004-07-09 + + * Correctly generate index * Allow generate simple JavaBeans that can be used in views. (eg. Torque Beans can't be used with Web Service and it's not a best practice use them with client) * Allow generate classes to translate Torque Beans in these simple Beans. + -- Domenico Loiacono 2004-08-05 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[DB Torque Wiki] Updated: NextRelease
Date: 2004-08-05T02:14:59 Editor: DomenicoLoiacono <[EMAIL PROTECTED]> Wiki: DB Torque Wiki Page: NextRelease URL: http://wiki.apache.org/db-torque/NextRelease no comment Change Log: -- @@ -43,3 +43,9 @@ * Add support for outer joins -- Don Vawter 2004-07-09 + +--- + * Correctly generate index + * Allow generate simple JavaBeans that can be used in views. (eg. Torque Beans can't be used with Web Service and it's not a best practice use them with client) + * Allow generate classes to translate Torque Beans in these simple Beans. +-- Domenico Loiacono 2004-08-05 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[DB Torque Wiki] Updated: NextRelease
Date: 2004-07-09T12:49:57 Editor: 24.8.10.18 <> Wiki: DB Torque Wiki Page: NextRelease URL: http://wiki.apache.org/db-torque/NextRelease no comment Change Log: -- @@ -39,3 +39,7 @@ * 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) + + + * Add support for outer joins +-- Don Vawter 2004-07-09 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[DB Torque Wiki] Updated: NextRelease
Date: 2004-04-27T06:53:14 Editor: ScottEade <[EMAIL PROTECTED]> Wiki: DB Torque Wiki Page: NextRelease URL: http://wiki.apache.org/db-torque/NextRelease typo only Change Log: -- @@ -21,7 +21,7 @@ * Correctly generate index and unique constraint names for PostgreSQL (see: ["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). + * Is it just me or are a number of the torque properties 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. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
