Support for multiple "databases"

[GoogleCodeExporter]

Hi,

I couldn't find a better way to contact you, sorry to be doing this through a 
ticket. I'd like to find 
out if you have planned support for multiple "databases" on a single server. I 
know the term 
varies based on engine but we have multiple schemas that are have foreign keys 
between 
databases using MySQL and I'd like to be able to use this tool to apply 
migrations. 

I'm going to dig into your code now. Please let me know if this is something 
you'd consider and if 
so whether you'd consider allowing me to commit a change.

Thanks,
Jon

jonrtodd@gmail.com

Original issue reported on code.google.com by JonRT...@gmail.com on 12 Oct 2009 at 10:29

[GoogleCodeExporter]

Jon,

Sorry for not getting back to you earlier, it's been a busy last few months.  
Here's
one way to support multiple schemas: Capture the migrations for each schema in a
different maven module.  For example, you might have a set of tables for 
capturing
CMS data; those could be in a cms module which include the migrations for the 
schema
plus all of the code that makes up the data-access-layer for those tables.  A 
second
module might capture user generated content in a different schema.  Bundling the
data-access layer with the schema works out nicely from an architecture 
standpoint
too.  Each schema ends up with its own schema_version table and their 
migrations are
tracked separately.  You can still trigger "mvn db-migration:migrate" at the 
root of
the project and have both schemas migrated. 

Where did you land with this?  Did you find an alternative solution or did you 
patch
db-migrations?

If you have the time, why don't we start up the conversation again and see what 
we
can do.

Original comment by christia...@gmail.com on 30 Dec 2009 at 11:36

[GoogleCodeExporter]

Having different maven modules won't fix the fact that the MigrationResolver is
always going to look in "classpath:classpath:/db/migrations" -- and the first 
module
in the CLASSPATH is going to win.

What I'm doing is:

* not using dbmigrate from maven, only from spring
* never using the default migrationsLocation, and setting up a different path 
per
database

So for each database with a different schema:

  <bean id="fooMigrationManager"
class="com.carbonfive.db.migration.DataSourceMigrationManager">
    <constructor-arg ref="fooDataSource" />
    <property name="migrationResolver">
      <bean class="com.carbonfive.db.migration.ResourceMigrationResolver">
        <constructor-arg value="classpath:/com/company/foo" />
      </bean>
    </property>
  </bean>

Original comment by matthew.mceachen on 13 Feb 2010 at 1:30