Open GoogleCodeExporter opened 9 years ago
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
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
Original issue reported on code.google.com by
JonRT...@gmail.com
on 12 Oct 2009 at 10:29