Managing databases for ORM based applications
Powerful ORM frameworks like hibernate and Ibatis and more recently JPA based ORM frameworks like Toplink, Hibernate and openJPA have taken a great deal of drudgery and error prone code out of the average enterprise application codebase. Many IDEs now provide powerful tool support for writing and maintaining code based on these frameworks. One effect of all this has been to move attention away from the database and into code, particularly in instances where developers are using automatic ddl generation from their ORM framework.
In such a situation, developers often don’t think about the effect that changes to their java code are having on the underlying database. Before there has been an initial release this may not necessitate migration of production data, but it can lead to large amounts of time wasted when changes in code necessitate schema changes, particularly if these changes clash with schemas other developers have established in their development environment. After an initial production release it can lead to serious problems if developers alter domain objects which are mapped using ORM frameworks. Simple XML or Annotation changes can wipe out or make redundant whole segments of the production database when released into the wild, or completely alter the semantics of existing data.
There is no doubt that a new discipline is required for developers when writing code using ORM frameworks. Paritcularly where there are multiple developers and potentially multiple production releases (pretty well every agile project I have ever known). This discipline should focus on the database schema that ORM frameworks are generating. Such schemas need to be versioned in the same way as the codebase is versioned. Luckily a tool called Liquibase exist for exactly this problem.
Liquibase provides for the creation and maintanence of database schemas and their data. I have not yet used it to make changes on production databases but we have been using it in development and it has had a very positive effect on productivity as developers no longer have to spend time working out why their tests are no longer working only to eventually discover that it is due to data changes conflicting with their existing schema.
Liquibase manages schemas and data through change sets and the database itself. It stores the change set ids in the database along with a checksum for the change set so that it can determine if the change set has been altered, invalidating it against that database.
With Liquibase in place the database can be generated and/or updated without the use of the ORM frameworks auto generation of DDL, in fact it is essential that this be turned of. For Spring applications a data migrator bean can be configured to automatically generate or update the database on startup of the application context and check that the schema is valid for application data mappings. If this is not desirable Liquibase has Ant targets and Maven goals that can be executed.