Comments on: Package Grails DBMigrations in your WAR File http://www.zorched.net/2008/06/10/package-grails-dbmigrations-in-your-war-file/ Musings of a software developer in Milwaukee, WI. Tue, 06 Jan 2009 05:06:54 +0000 http://wordpress.org/?v=2.7 hourly 1 By: Geoff Lane http://www.zorched.net/2008/06/10/package-grails-dbmigrations-in-your-war-file/comment-page-1/#comment-12723 Geoff Lane Wed, 11 Jun 2008 21:00:10 +0000 http://www.zorched.net/?p=112#comment-12723 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. 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.

]]> By: Shawn Hartsock http://www.zorched.net/2008/06/10/package-grails-dbmigrations-in-your-war-file/comment-page-1/#comment-12721 Shawn Hartsock Wed, 11 Jun 2008 20:48:01 +0000 http://www.zorched.net/?p=112#comment-12721 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. 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.

]]>