Best Practice: SQL Scripting or Trusting GORM

Question

I have always scripted all DB changes. But I'm wondering if I really need to do that with Grails applications, since GORM will make the changes automatically.

So what's the best practice for managing database changes in a Grails application?

Answer 1

GORM won't handle all schema changes automatically; for example, if you delete a field from one of your domain objects, GORM won't delete the corresponding database column.

There are a couple of Grails plugins to manage database migration - see Autobase and Liquibase. I'd say that using whichever of these meets your needs more closely is the best practice; here's a good blog post that explains a few gotcha's with both plugins.

Answer 2

This is the pattern that I've used on several large Grails projects (and some smaller ones):

1. In GORM we trust™ for the first stages of development (pre-production / without data)
2. Just before releasing to the production environment start using a tool like Autobase, Liquibase, Database Migration Tasks (similar to RoR's rake), or another schema versioning utility.
3. Maintain all database changes through the tool in an automated fashion.
4. Test your migrations, by writing tests that exercise corner cases and data integrity to the level that you are comfortable running them on production data.

I wouldn't use straight GORM in production unless it is a smaller project that can handle a few possible speed bumps and manual interventions.

Once you start managing several environments (local development, QA/UAT, Staging, Production) you be glad that you spent the time to manage your DB changes.

Liquibase and Autobase both give you some good tools for writing many of the common refactorings, but you can always drop down into raw SQL if you want/need to.