Comments on: Liquibase Incremental DB Diff

By: Liquibase! (Part 2) | Cantina Consulting

Liquibase! (Part 2) | Cantina Consulting — Tue, 02 Nov 2010 11:51:50 +0000

[...] some code. The dbdiff script we’ve been using is based on work done by Jakob Külzer , and many thanks to him for the idea. We’ve augmented his idea such that instead of using [...]

By: Liquibase! (A brief primer on database schema migrations in Grails) | Cantina Consulting

Fri, 03 Sep 2010 16:04:29 +0000

[...] be a problem. For flexibility we’ve added a custom environment and a new script (based off of this idea). The script compares your dev and custom environments against one another and prints out the [...]

By: Justin Miranda

Justin Miranda — Sat, 14 Aug 2010 01:35:28 +0000

Thanks for the great posts — I’ve been extracting a lot of good bits of information from your Grails/Liquibase posts. I’m having some difficulty with the diff process (using the Liquibase db-diff or your script). I want to be able to run the ‘dev’ database using dbCreate = ‘create-drop’ so that I can make changes to the domain and then, every once in a while, run the db-diff script to figure out what’s changed and add that to my changelog. However, what I’ve noticed is that the db-diff creates a huge number of changesets for dropping/creating foreign key constraints. This is obviously due to the fact that the “create-drop” will re-create the foreign key indices (with an auto-generated name) each time. So how do you get a reasonable diff if 90% of the changesets are garbage. Do you just parse through the changesets and grab the ones that you want to include in your changelog?

By: Jakob Külzer

Jakob Külzer — Wed, 27 Jan 2010 21:23:01 +0000

Agreed, the script is not very flexible but it could easily be improved.

It still requires the user to manually modify the datasources though, because Liquibase is kind of sensitive to different databases. E.g. diff’ing an HSQLDB database against a MySQL database will not go well.

I like the above approach, injecting the configuration during runtime, but it still leaves the question of how to get the database driver right…

Ideas?

By: diffing

diffing — Wed, 27 Jan 2010 20:52:46 +0000

previous suggestion won’t work for external configurations specified on classpath (needs to be modified).

By: diffing

diffing — Sat, 23 Jan 2010 02:07:51 +0000

Great stuff. This is exactly what I was hoping for.

However, like the original DbDiff.groovy script this does not seem to work with external configurations — i.e. the expected DataSource.groovy does not contain the environment settings (instead they are in an external file located at grails.config.locations — or in this case it does not exist at all).

line:

def testConfig = testConfigSlurper.parse(classLoader.loadClass(“DataSource”))

changed to lines:

def testConfig
try {
testConfig = testConfigSlurper.parse(classLoader.loadClass(“DataSource”))
}
catch (e) {}

if ( testConfig != null ) {
config.grails.config.locations.each({ testConfig.merge(testConfigSlurper.parse(new File(it.split(“:”)[1]).toURL())) })
} else {
testConfig = config.grails.config.locations.inject(new ConfigObject()) { aNewConfig, item -> aNewConfig.merge(testConfigSlurper.parse(new File(item.split(“:”)[1]).toURL())) }
}

Seems to work.