Comments on: Agile database schema migration tool for Java

By: spullara

spullara — Mon, 08 Mar 2010 00:20:15 +0000

Looks interesting but is ridiculously expensive.

By: chris

chris — Sun, 07 Mar 2010 23:49:45 +0000

Hi Sam,

You may want to checkout ChronicDB, which applies database schema updates without downtime: http://chronicdb.com

By: harry

harry — Sun, 23 Aug 2009 13:23:44 +0000

The same thing with Oracle, every DDL operation includes an implicit commit so the ability to roll back a schema change using traditional means is not possible. Although that specific RDBMS includes other ways to possibly overcome the problem of reverting back changes that go beyond transaction level using a feature called flashback database.

I also agree that the ability to revert back failed migration step is crucial for actually testing the steps and ensuring that they all work correctly before applying them to any production environment. The problem currently is just how to actually do it in a foolproof way.

By: harry

harry — Sun, 23 Aug 2009 06:23:44 +0000

By: sam

sam — Wed, 26 Nov 2008 06:57:45 +0000

Hi Miguel,

I’m pretty sure that MySQL doesn’t support DDL + transactions like PostgreSQL does. If it does, I will fix it but that is my understanding.

Sam

By: miguel

miguel — Wed, 26 Nov 2008 06:51:20 +0000

it seems that the migration tool doesn’t do the migration as a transaction. i haven’t looked into the code, but got an error while it was running, but part of the script still ran. this was on mysql5 and it was jsut a create table command, it failed because there was no version table yet.

By: Andrew Eells

Andrew Eells — Mon, 29 Sep 2008 19:07:53 +0000

I have created and released under the GPL a versioning framework for
database release patching. This has been tested and used in an Agile
development environment with multiple users throughout all stages of
the development lifecycle.

You can find details here: http://www.andrew-eells.com/database-versioning-framework/

I would like to make a section of the development community aware of
this, really to see what response I might get, and possibly to help
anyone who needs a framework for similar purposes.

Please feel free to download and use it within your project team, and
I’d be really grateful for any comments on improvements you think
could be made.

Thanks and regards, Andrew

By: sam

sam — Thu, 14 Feb 2008 17:51:36 +0000

The code is maintained at Google Code. Codehaus only has the code for the plugin because thats the way you distribute plugins using grails — they are uploaded to the codehaus SVN server. Anyone who is serious about working on the project only need contact myself and I will add them to the project with their first good patch.

By: Arnon

Arnon — Thu, 14 Feb 2008 17:46:25 +0000

Good work Sam.
Where do you maintain it now? There seems to be confusion as to whether it’s in google code or codehaus…

By: sam

sam — Sat, 13 Oct 2007 04:47:50 +0000

Sounds very similar to autopatch (http://autopatch.sourceforge.net), which i’ve been using for a couple of months on a java web project. It’s more web app focused, with some nice features like a startup servlet to trigger the migration when you deploy a new version of your app, and a locking table to prevent multiple nodes in a cluster from trying to update simultaneously. So far the biggest annoyance of autopatch has been that the migrations are one way. I like the fact that rake migrate lets you downgrade your database so you can re-run the upgrade as you test your app before checking in.

Autopatch actually looks like a really cool generic solution to this problem. If it had been easy to find perhaps I would not have built this though its probably a bit too generic for most people (but not me). I’ve never had an application setup so that I would need to downgrade, instead I always use original data in the tests and have it get upgraded up to current. That makes it a waste to write all that downgrade code, especially when a true downgrade may be impossible (loss of information during migration).