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

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).

Hi Sam,
Just been looking at dbmigrate to handle our database migration issues during development. Looks like a very promising product.

Thanks, I am obviously still working on it but its working well in its current implementation.

One area that has me scratching my head a bit is the processing of the scripts. It’s a bit out of sync with the doco, so I’ve been running some tests to see how it works and looking through the source code. I’d like some feedback on the reasoning behind the mirgratefrom- and migrateto- seperating of the classes/scripts. The code says that it looks for the first file from the list and runs just that one. The search order being (ignoring database specific ones which are the same):

(Class)from(version)
(Sql)from(Version)
(Groovy)from(version)
(Class)to(version+1)
(Sql)to(Version+1)
(Groovy)to(version+1)

I found this a bit confusing and wondered what the logic behind this is. I also found that if I create a from1, from2, and from3, dbmigrate only runs 1 and 2 when I specify version 3. I tried changing from3 to to3, but because of the from2 script it would not run that either.

It appears that the logic is that from scripts update from the prior version to the next number, I.e. from2 should contain updates from version 2 to version 3 of the database and the to scripts work in the opposite. But that you must code either from or to scripts, but not both. In which case I’m thinking why not just stick with what the doco says.

It appears that the best way to code things is to create to1, to2, and to3 as most programmer think in terms of the version number of a file matching the version number in the database.

So here is the deal. The original one had the semantics of ‘migratefromN’ which is what I need in order to skip versions for when you go GA and you want to update the database in one fell swoop from the previously released version to the latest development version. The problem is that if you keep track of the version you are going to you have this problem that you must assume that you are coming from the most immediate previous version. For all those people out there that want the version of the file to match up with the version of the database you can use ‘migratetoN’ scripts/classes. I should really update the documentation but this was after feedback like yours where you want the script version to match the database version it is setting rather than the version it finds in the database.

Regards,
Derek

P.S. What’s the status of the code in terms of contributions from other programmers ? How would we go about it ? and how much time do you expect to put into this project ?

Right now it is just myself and a couple of others that have worked on before. If you or someone from your team wants to contribute we can discuss it. Send me email (sam at sampullara dot com). In terms of time I am going to put into the project — I would like to limit the scope of it so that in its current form it is almost done and if there is more to it, perhaps make another system that sits on top of it.

One area that has me scratching my head a bit is the processing of the scripts. It’s a bit out of sync with the doco, so I’ve been running some tests to see how it works and looking through the source code. I’d like some feedback on the reasoning behind the mirgratefrom- and migrateto- seperating of the classes/scripts. The code says that it looks for the first file from the list and runs just that one. The search order being (ignoring database specific ones which are the same):

(Class)from(version)
(Sql)from(Version)
(Groovy)from(version)
(Class)to(version+1)
(Sql)to(Version+1)
(Groovy)to(version+1)

I found this a bit confusing and wondered what the logic behind this is. I also found that if I create a from1, from2, and from3, dbmigrate only runs 1 and 2 when I specify version 3. I tried changing from3 to to3, but because of the from2 script it would not run that either.

It appears that the logic is that from scripts update from the prior version to the next number, I.e. from2 should contain updates from version 2 to version 3 of the database and the to scripts work in the opposite. But that you must code either from or to scripts, but not both. In which case I’m thinking why not just stick with what the doco says.

It appears that the best way to code things is to create to1, to2, and to3 as most programmer think in terms of the version number of a file matching the version number in the database.

Regards,
Derek

P.S. What’s the status of the code in terms of contributions from other programmers ? How would we go about it ? and how much time do you expect to put into this project ?

1) I like this idea.
2) Seems reasonable. That might make it easier to read and understand what would get executed.
3) Now that I have integration with Grails I might add the ability to specify the environment even in the Java version.
4) Actually as of subversion version 40 or so I support Groovy scripts (named like the sql scripts), Java classes (camelCased), and SQL scripts.

Sam

A couple of thoughts for you moving forward:
- I think you might want to consider breaking up schema from data. The data itself might change based on the environment, especially for initial loads.
- I think separating by database vendor could be done optionally in the naming of the file itself, e.g. migratefrom01_postgres.sql or migratefrom01.sql. I think it fairly likely that the sql will be independent.
- I use something like this for a structure
- schema
- baseline_schema.sql
- schema_updates.sql (could be migrations here, further separated by vendor)
- data
- dev
- baseline_data.sql (could also be migrations, the system always does schema then data)
- data_updates.sql
- production
…
- A final nice feature would be to have the system pick up SQL OR Groovy scripts, in case you want to do some serious logic for a migration.

Once again, nice work.

- John

Checkout Liquibase: http://www.liquibase.org/
“LiquiBase is an open source (LGPL), DBMS-independent library for tracking, managing and applying database changes. “

I like the backend of this library. Not too fond of creating XML to do the changes though. Though one of the uses I see for this is adding migrations to Grails. Then creating a builder that has a nice DSL and generates the XML configuration files might not be that bad. I’ll check it out, thanks for the link!

Hi, I’m one of the developers of LiquiBase and ran across this blog today. I had actually started making a LiquiBase Grails plug-in as a way to start learing the platform. It’s not very far along so far, but I don’t see it as being particularly difficult (time is the main reason it’s not far along). I’ve had requests for a non-XML DSL for changes in the past and am not against the idea. We’ve gone with XML mainly so we can leverage the existing XML parsers and because IDEs have built in XML auto-completion. There may be a way to combine the two, however.

I agree that some sort of schema migration tool would be a great addition to Grails, but I don’t want to double up on the effort. Let me know if you’d be interested in working together.

Nathan