protected String convertMigrationsLocation(DatabaseType dbType, String migrationsLocation)

otherwise I’d have to clone essentially the whole ResourceMigrationResolver class.

I found a more explicit way of implementing this, at least in spring, but I don’t think it’s as nice (but it’s what I’m doing for now); I’m going to provide the subdirectory as a configuration parameter:

and dbtype is specified in the same file that has the db connectivity information.

Thanks for pushing the release, and I apologize for the death-by-a-thousand-patch-cuts.

When will you cut the next release?

Thanks! We usually handle different db types using Maven profiles. Each profile points to a different migration directory (src/main/db/mysql, src/main/db/postgres, etc). It’s not that common a use case for most of our projects.

I’m happy to make the change to the MigrationResolver interface and take a look at your patch to see how I can work it to the project. Why don’t you create a ticket (http://code.google.com/p/c5-db-migration/issues/list) and include your patch?

Take care,
Christian

I’ve been using another dbmigrate implementation that supports different migration steps for different database types (so one directory holding MySQL DDL and another with h2 DDL). That’s proven handy so we can unit test with h2 and run with MySQL.

It would be a fairly small patch to MigrationResolver to make them “DatabaseType”-aware: Set resolve(DatabaseType dbtype);

And then the migrationsLocation could have the dbtype added as a sub-directory suffix, so you’d construct a new subclass of ResourceMigrationResolver with “classpath:/com/abc/project” and then depending on your datasource’s DatabaseType, either “/mysql” or “/h2″ would be appended to the database type.

By being a new subclass, the old behavior would be unaffected.

How do you guys use different database types (one for testing, one for production)?

I have a developed similar tool.
http://code.google.com/p/garindriver

My tool supports a model with an internal schema manager scripts, JDBC driver wrapper automatically recording of DDL/DML, distributed locking model, and a few other features.

GarinDriver currently supports it’s internal schema manager and also provides a link into liquibase schema manager. With the model I use it should be possible to also link into your migration project if it looks like a good fit. The basic concept of GarinDriver is to automatically delegate to the migration system at JDBC driver connect time using a model where the client can identify the backend JDBC database and required level. GarinDriver will AUTOMATICALLY invoke migrations prior to returning the connection.

In any case, please checkout the project and let me know what you think. It is possible that we could work together a bit to allow your project link into the event chain if you feel that it makes sense.

-Mark

Have you found a strong case for rolling back in your experience?

This is a great looking plugin – we’ve just hooked it in to our CI process and are expecting good things.

The plugin looks fully featured with the exception of rolling back to prior versions a la the way it’s done in Rails. Was this a deliberate step to enforce process, or just a feature that has not been implemented yet?

Thanks,

- max

Works like a charm. I actually ended up extended ResourceMigrationResolver and used the hibernate dialect, which i already had to set the migrationsLocations

Using maven profiles, you can create a profile for each database supported. In each profile, you can set a property called “dbtype”. Then, in you db-migration configuration, you can override the migrations path like this: file:src/main/resources/db/${dbtype}/migrations/*

I’ll add a more complete example to the documentation one of these days. Good luck!

Just picked up 0.9.3 and i can get it to run against the hsql databse. Much appreciate for the quick turn around. Now i have a question around managing the migration across a number of different databases. For instance the sql that hibenrate spits out for hsql is different to that for mysql.

Is there a mechanism to handle this at the moment?

cheers

Very timely indeed. Thank you very much.

Do you have an rough idea when you will be doen with the refactor

HSQL just doesn’t support the ‘unique’ constraint in the create table construct. I am using MM directly in my code.

I will also look at H2Database

cheers

What is the correct DDL SQL for creating the version table for HSQL?

Another alternative is to switch to H2Database. It’s written by the same team as Hypersonic and is actively developed, unlike HSQL.

I’m midway through a refactor which will allow for better handling of dbms-specific features. When it’s done, it will be easier to handle these cases more gracefully than the framework allows for now.

Caused by: java.sql.SQLException: Unexpected token: UNIQUE in statement [create table schema_version (version varchar(32) not null u
nique]

I believe that HSQL v1.9 will rectify this problem but there is no release date as yet. Am i able to use my own definition for the schema version table

cheers

I did some testing against MS SQL Server and found one issue which has been resolved in 0.9.2-SNAPSHOT. So, I’ve successfully run all of the functionality against SQL Server 2000. If you’re up for it, switch to that SNAPSHOT and give it a try. Let me know how it goes. -Christian