Migrations: Embedded call in JavaEE-Application (In-App-Migration)

[GoogleCodeExporter]

My current project is a multi tenant web application (Spring 3.1, but shouldn't 
matter) that is deployed as a WAR artifact.

Dependending on the tenant id, a SQL datasource is looked up from JNDI.

I would like to be able, to get a SQL datasource from JNDI and let Migrations 
check the database behind this SQL datasource for any pending changes (and 
apply them) during initialization phase of my application.

So what I need is:

- a way to submit a SQL datasource/JDBC connection for use to Migrations
- give Migrations a base Java package instead of a directory where it finds its 
diff files and configuration. These files would get bundled with the release.

- Further it would be nice to have Migrations check for any changelog entries, 
that don't exist as diff files to identify cases, where the database is too new.

Original issue reported on code.google.com by christia...@googlemail.com on 15 Aug 2012 at 3:32

[GoogleCodeExporter]

Original comment by chengt on 15 Aug 2012 at 7:16

[GoogleCodeExporter]

Original comment by eduardo.macarron on 16 Aug 2012 at 4:57

• Added labels: Component-Migrations

[GoogleCodeExporter]

I changed the BaseCommandClass to have support for an external datasource so 
one can call Commands inside an application server from application code.

The next step will be to refactor the code that gets the patches and other 
files from the file system from some vfs-abstraction so one can put all the 
stuff into release jar files.

I would be happy if you would apply my first patch to the trunk.

Original comment by christia...@googlemail.com on 25 Sep 2012 at 1:52

Attachments:

• external_datasource.patch

[GoogleCodeExporter]

Hi,

I have been working on this recently and would like to hear your opinions.

Here's the branch:
https://github.com/harawata/migrations/tree/in-app-migration-support

The test case 'JavaApiTest' would explain its usage, but here's how you would 
call the API.

new UpOperation().operate(
  new DataSourceConnectionProvider(dataSource),
  migrationsLoader, // see below
  new DatabaseOperationOption(),
  null
);

There are two new interfaces:
- ConnectionProvider provides connection.
- MigrationsLoader abstracts where and how to load migration scripts.

For your first request, the bundled DataSourceConnectionProvider would be 
sufficient.

For the second request, I didn't include the actual implementation because 1) 
it could be very complicated to support various situations and 2) there already 
are some libraries which do the job better (e.g. Spring Frameworks 
PathMatchingResourcePatternResolver and Reflections 
[https://reflections.googlecode.com]).
So, you would have to create an implementation of MigrationsLoader to load SQL 
scripts from a JAR.
The following test project contains basic example of these implementations.
https://github.com/harawata/mybatis-migrations-custom-loader

There is a new ticket for this on GitHub.
https://github.com/mybatis/migrations/issues/2

Any thoughts or advice?

Regards,
Iwao

Original comment by haraw...@gmail.com on 10 Jul 2013 at 11:55