Best Practice: SQL Scripting or Trusting GORM

Question

I always wrote down all database changes. But I wonder if I really need to do this with Grails applications, as GORM will automatically make the changes.

So what is best for managing database changes in a Grails application?

Answer 1

This is the template I used for several major Grails projects (and some smaller ones):

• At GORM, we trust ™ for the first stages of development (pre-training / no data)
• Before releasing the production environment, he will start using a tool such as Autobase , Liquibase , Database migration tasks (similar to RoR rake) or another version control utility.
• Maintain all database changes through a tool in an automated mod.
• Test your migrations by writing tests that run corner cases and data integrity to a level that you are more comfortable with on production data.

I would not use the direct GORM in production, if it is not a smaller project that can handle several possible speed hits and manual interventions.

As soon as you start managing several environments (local development, QA / UAT, Staging, Production), you will be glad that you took the time to manage changes to the database.

Liquibase and Autobase give you good writing tools for many common refactoring, but you can always give up raw SQL if you want / need.

Answer 2

GORM will not process all circuit changes automatically; for example, if you delete a field from one of your domain objects, GORM will not delete the corresponding database column.

There are several Grails plugins for managing database migration - see Autobase and Liquibase . I would say that using the one that best suits your needs is the best practice; here's a nice blog post that explains a few gotcha with both plugins.