[ https://issues.jboss.org/browse/FORGEPLUGINS-54?page=com.atlassian.jira.p... ] darren hartford edited comment on FORGEPLUGINS-54 at 10/2/12 10:36 AM: ----------------------------------------------------------------------- Feature *wish* list (starting with what would be desireable versus achievable): *Bi-directional Incremental change support. I do not recall where, but this was a black eye for Forge/Hibernate reverse engineering in one review ('destructive' was a word used to describe it, which is unfair when you talk reverse engineering tool versus change management tool) when compared to Grails and Roo. --change in database schema and have 'incremental' change support to domain code...without replacing existing code (example, if you modified the JPA design to include TABLE_PER_CLASS inheritance, and you add a new column to one of those tables or a separate class that as one-to-many to that inheritance, do not want to loose that work). --change the domain in code, incrementally handle db migration. Note that column renames need to be specifically addressed, and some type of ability to *track* other columns marked for deletion, but not actually purge unless explicitly defined. *SQL support to handle more database-specific work, like data migration work (if merging or breaking apart data in column(s) to other column(s)). *SQL specific schema support -- Specifically, there may be additional columns/relations in the table design that do not/are not part of the domain model. This should be supported with some type of 'ignore' feature when working on the code-domain but still exist/support/be upgraded as part of the upgrade process (new/improved indexes, constraints, spoc/functions, sql views for example). Not primary feature of this plugin, but should support it. *Control data population (setting default values, app-specific values, environment/client values, etc). *Application-deploy upgrade process, cluster aware (avoid multiple apps upgrading the schema at the same time) -- have support to (optionally) auto-upgrade database schema when deploying newer application. This should support multi-version upgrade (optional to control size/number of diff/changes -- if database schema was for application v3, and now deploying application v5, but able to upgrade through all changes). --caveat, one of the comments against this approach is the upgrade library/code and the upgrade scripts would 'always' be packaged with the application, versus only needed once per upgrade. There is no way around this without introducing additional external support (separate system) or separate artifact like an 'app-upgrade.war' sibling that can be undeployed without impacting the real application (potentially deploy both, have the real application have lightweight version to check db version matches need for application version, if not call/wait for upgrade artifact, then undeploy/remove the upgrade artifact). *Support both code-first and database-first kickstart (how/where to baseline the database). *(nice to have) - ability to know what changes are backward compatible from the application domain code and the database changes point-of-view, versus those that are not. For example, adding new columns that are nullable and no FK constraint are backward compatible allowing the prior applications to continue to function during the upgrade. This is useful for stepped upgrade processes for minimal downtime. was (Author: dhartford): Feature *wish* list (starting with what would be desireable versus achievable): *Bi-directional Incremental change support. I do not recall where, but this was a black eye for Forge/Hibernate reverse engineering in one review ('destructive' was a word used to describe it, which is unfair when you talk reverse engineering tool versus change management tool) when compared to Grails and Roo. --change in database schema and have 'incremental' change support to domain code...without replacing existing code (example, if you modified the JPA design to include TABLE_PER_CLASS inheritance, and you add a new column to one of those tables or a separate class that as one-to-many to that inheritance, do not want to loose that work). --change the domain in code, incrementally handle db migration. Note that column renames need to be specifically addressed, and some type of ability to *track* other columns marked for deletion, but not actually purge unless explicitly defined. *SQL support to handle more database-specific work, like data migration work (if merging or breaking apart data in column(s) to other column(s)). *SQL specific schema support -- Specifically, there may be additional columns/relations in the table design that do not/are not part of the domain model. This should be supported with some type of 'ignore' feature when working on the code-domain but still exist/support/be upgraded as part of the upgrade process (new/improved indexes, constraints, spoc/functions, sql views for example). Not primary feature of this plugin, but should support it. *Application-deploy upgrade process, cluster aware (avoid multiple apps upgrading the schema at the same time) -- have support to (optionally) auto-upgrade database schema when deploying newer application. This should support multi-version upgrade (optional to control size/number of diff/changes -- if database schema was for application v3, and now deploying application v5, but able to upgrade through all changes). --caveat, one of the comments against this approach is the upgrade library/code and the upgrade scripts would 'always' be packaged with the application, versus only needed once per upgrade. There is no way around this without introducing additional external support (separate system) or separate artifact like an 'app-upgrade.war' sibling that can be undeployed without impacting the real application (potentially deploy both, have the real application have lightweight version to check db version matches need for application version, if not call/wait for upgrade artifact, then undeploy/remove the upgrade artifact). *Support both code-first and database-first kickstart (how/where to baseline the database). *(nice to have) - ability to know what changes are backward compatible from the application domain code and the database changes point-of-view, versus those that are not. For example, adding new columns that are nullable and no FK constraint are backward compatible allowing the prior applications to continue to function during the upgrade. This is useful for stepped upgrade processes for minimal downtime. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira