[ https://issues.jboss.org/browse/FORGEPLUGINS-54?page=com.atlassian.jira.p... ] darren hartford commented on FORGEPLUGINS-54: --------------------------------------------- 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. -- 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