[forge-issues] [JBoss JIRA] (FORGEPLUGINS-54) Plugin to Database Migration Framework

Tue Oct 2 10:31:02 EDT 2012

    [ https://issues.jboss.org/browse/FORGEPLUGINS-54?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12723309#comment-12723309 ] 

darren hartford edited comment on FORGEPLUGINS-54 at 10/2/12 10:29 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.

*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).

> Plugin to Database Migration Framework
> --------------------------------------
>
>                 Key: FORGEPLUGINS-54
>                 URL: https://issues.jboss.org/browse/FORGEPLUGINS-54
>             Project: Forge Plugins
>          Issue Type: Feature Request
>            Reporter: Mauro Silva
>
> Recommend idea for adding a database change plugin. The Grails plugin for database changes (http://grails.org/plugin/database-migration) may be good for inspiration, however the Forge version may not necessarily have the tightly coupled support as the Grails/Groovy domain models have, but something that supports JPA would be fabulous.
> Although a generic plugin for Liquibase or other database change management support could be useful, it would be left 'up to the developer' on how to use it which seems counter-intuitive to a more RAD-style development environment, per the specific of JPA-based data access (potentially OGM-based JPA as well).
> Usecase is for solving how to deploy database structure changes in an automated fashion to ensure the database schema does not go out of sync with the application.
> A Plugin like spring-roo-addon-flyway (http://code.google.com/p/spring-roo-addon-flyway/).
> Could be other Database Migration API that works better on Jboss ecosystem (I dont know if that is one).

--
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