This was a great help. There aren’t many tutorials for this plugin. One thing I would like to point out is that I had to add a columnDataType as an argument to addNotNullConstraint in your “Multiple Step Migration.” Apparently that is a requirement of some databases (MySQL in my case).
I used postgres for this example and didn’t have that problem with needing columnDataType. Would you mind sending me the source of what your migration ended up looking like? I’ll update the post to cover that for other MySQL users.
Hi, David. Sorry that this issue came up for you as well.
This issue is, in fact, database specific. To see what’s going on under the hood, I would take a look at the liquibase docs. Here is the documentation for this migration in particular: addNotNullConstraint. Here you can see that the “columnDataType” attribute that Weezle needed is specific to MySQL/MS-SQL, but may also be related to what you’re seeing. If you are using the HSQL in-memory database, this page says that there may be a bug that causes failures unrelated to how you are attempting to write the migration, but could actually be related to the data in your tables.
I would give the solution from that stack overflow answer a try and please let me know if that helps. If not, you may need to dig into the HSQL bug that the page I linked references. I’ll put an edit in the post to mention this, but will likely leave my projects as they are since I’m using PostgreSQL and it works as is.
Hi, great tutorial, thank you! I wanted to ask about deploying to production, once you have all the migration scripts, is there a way to hand them off to a deployment team without requiring they have grails installed to run the grails command dbm-update on a production server?
Glad that the tutorial was helpful! As far as deploying to production: since the focus here is on the grails plugin, it does require that grails be installed wherever you are running the scripts. For me, personally, I don’t have a need to “hot deploy” these changes with the app running, so I have the luxury of stopping grails, running the db migration using grails, and starting the app again. If it is important for you to have a migration process that is completely independent of grails that is certainly possible, but, unfortunately, I don’t have a lot of insight into what tools would be best for the job. Good luck!
This is a great walk-through! In the plugin version I’m using (1.2.2), there are a couple of commands that generate the sql that would be run by dbm-update (e.g., dbm-update-sql and dbm-previous-changeset-sql). The generated sql could potentially be handed off to a deployment team. We haven’t made it to prod with our changes yet, but are considering trying this.
will greenway 
This was a great help. There aren’t many tutorials for this plugin. One thing I would like to point out is that I had to add a columnDataType as an argument to addNotNullConstraint in your “Multiple Step Migration.” Apparently that is a requirement of some databases (MySQL in my case).
Glad to hear it was helpful.
I used postgres for this example and didn’t have that problem with needing columnDataType. Would you mind sending me the source of what your migration ended up looking like? I’ll update the post to cover that for other MySQL users.
Does HTML work in these posts? I made a question on Stack with the relevant code
Hi wpgreenway, I went thru your blog dbmigrate example and I’m having the same issue as Weezle.
The only diff is I’m only using the in memory DB.
DB choice should not make a difference IMHO but I’m still trying to get a footing under how to use the dbmigrate tool.
Any chance you will update your blog example or am I better off using the changes indicated on StackOverFlow fix?
Hi, David. Sorry that this issue came up for you as well.
This issue is, in fact, database specific. To see what’s going on under the hood, I would take a look at the liquibase docs. Here is the documentation for this migration in particular: addNotNullConstraint. Here you can see that the “columnDataType” attribute that Weezle needed is specific to MySQL/MS-SQL, but may also be related to what you’re seeing. If you are using the HSQL in-memory database, this page says that there may be a bug that causes failures unrelated to how you are attempting to write the migration, but could actually be related to the data in your tables.
I would give the solution from that stack overflow answer a try and please let me know if that helps. If not, you may need to dig into the HSQL bug that the page I linked references. I’ll put an edit in the post to mention this, but will likely leave my projects as they are since I’m using PostgreSQL and it works as is.
Hi, great tutorial, thank you! I wanted to ask about deploying to production, once you have all the migration scripts, is there a way to hand them off to a deployment team without requiring they have grails installed to run the grails command dbm-update on a production server?
Glad that the tutorial was helpful! As far as deploying to production: since the focus here is on the grails plugin, it does require that grails be installed wherever you are running the scripts. For me, personally, I don’t have a need to “hot deploy” these changes with the app running, so I have the luxury of stopping grails, running the db migration using grails, and starting the app again. If it is important for you to have a migration process that is completely independent of grails that is certainly possible, but, unfortunately, I don’t have a lot of insight into what tools would be best for the job. Good luck!
This is a great walk-through! In the plugin version I’m using (1.2.2), there are a couple of commands that generate the sql that would be run by dbm-update (e.g., dbm-update-sql and dbm-previous-changeset-sql). The generated sql could potentially be handed off to a deployment team. We haven’t made it to prod with our changes yet, but are considering trying this.