The Grails DBMigrate Plugin is a handy way to give you control over the generation of your database if you don’t want Grails to auto-munge your schema. It works fine in development, but when you create a WAR for deployment on another machine the Migrations are not packaged in the WAR so the database can’t be created or updated.
Packaging DBMigrate Scripts for Deployment
Here’s the quick solution to package your DBMigrations in your WAR file.
Just add this to your Config.groovy file and when you generate the WAR the migrations will be included and found by the Plugin.
grails.war.resources = {stagingDir -> copy(todir: "${stagingDir}/WEB-INF/classes/grails-app/migrations") { fileset(dir:"grails-app/migrations") } }
Aside
The only problem with DBMigrate is that it doesn’t handle creating or updating Stored Procedures and Functions which means if you want to use those – for Reporting purposes lets say – you’re out of luck currently.
Actually, I started researching Hibernate Events because I saw that stored procedures were not well represented in some circumstances. I am currently of the mind that if you can “package” your “triggers” inside the domain object that’s probably a good thing for the most part. It does mean that you have more complicated domain classes, but, you keep all your work in Groovy/Java which is portable and centralized instead of spreading the trigger into the Database. In short you work your data model from inside the Grails domain classes and try to put all data model related things there.
There are drawbacks to that approach but if your shop is mostly Java/Groovy coders and resource constrained on DBA and PL/SQL development then you could actually save a context switch for your development team.
Shawn,
Hibernate events can definitely work well. And the post you link to is a great example! I’ve used that technique in the past (in pure Java/Hibernate) for keeping historical records as well.
Where stored procedures and other database objects shine when you want to get out of your Groovy/Java code though. If everything is running through that code then no problem. But get into reporting using an external tool and all of a sudden accessing those domain classes and Hibernate events becomes non-trivial.
I also believe that databases are fundamentally better at some tasks and we should leverage them when we can.
Thanks for the comment.