I can’t remember how I survived before the Database Migration plugin. Being able to deploy upgrades to client site without having to worry about which old version they were previously running is very comforting. It’s the second plugin I install after Spock.
There are a few rough edges that I have encounter with the output of good old dbm-gorm-diff, and always end up doing a little bit of hand editing. Sometimes it generates FKs that are too long for my final target. Sometimes it creates varchars when I was after longvarchars and so on. But mostly it gets it right, so I don’t mind a little hand editing.
Yesterday I was bitten by an issue surrounding floating point precision. I was feeding in some floating point data of fairly small precision (eg 123.45) and was getting back floating point with massive precision (123.450275639457236394). Wat?
Turns out this one is a known issue with the Liquibase and the Db Migration plugin which others have hit too. But when you see the behaviour in the your app, it can be hard to know where to start.
The thing you need to know is that if you specify a property of type Double in your Grails app, the migration plugin with generate a db script of:
column(name: "my_double_field", type: "double precision(19)")
Even if you haven’t specified any scale constraint on the field in your domain class. And that precision can cause havoc with what Liquibase generates into your db tables. On SQL Server, that will generate a field as a “real” rather than a “float”. And the kicker will be if your looking at the data inside SQL Management Studio, it will look fine :-). But as soon as you query it from jdbc, then hang on to your screen real estate for the floating point precision!
So the fix is pretty simple. Just edit your migration file and lose the precision:
column(name: "my_double_field", type: "double")
So keep it real. And checkout out your generated SQL!
(PS, we’re working hard on Grails In Action 2.0 and the MEAP is now out! )