The application I work on uses two databases; one for ordinary data and one for a data warehouse. Both databases are developed as part of the application (i.e. as part of the same Rails project). All is fine at the ActiveRecord level (I'm using establish_connection to associate data warehouse specific models to the right database). However, as far as I can tell migration support for this scenario isn't quite there yet.
What I would like to be able to do is to have two separate sets of migrations, one for each database, so that I could specify (in database.yml) e.g.:
development:
adapter: postgresql
database: development
...
and then place all my "ordinary" migrations in db/migrate as usual, and all the data warehouse related migrations in db/migrate/datawarehouse. Provided that I also provide a datawarehouse_development.rb, I should then be able to apply the migrations by specifying the proper RAILS_ENV:
Looking at database.rake it seems that all that is needed are two small changes so that it (1) passes a migrations path to ActiveRecord::Migrator#migrate that includes (if present) the 'migrations' value from the current RAILS_ENV and (2) includes any such migration set name in the name of the schema file used by db:schema:dump.
I'm sitting on a tiny patch which accomplishes this -- would it be of any interest?
We've got a home backed migrator that adds a "brick" column in
schema_migrations so you can run only the migrations in a specific
bricks folder and easily revert all migrations from a given brick.
The migrations in zena are located in folders like this:
bricks/sphinx/migrate
bricks/tags/migrate
It should not be too hard for you to hack around this Migrator to fit
your needs. You then run the required migrations with
rake zena:migrate BRICK=sphinx
If you run
rake zena:migrate
All migrations are run and those in db/migrate get a "NULL" column in
the brick name so it's compatible with rail's db:migrate.
Thanks for the response. I think my situation is somewhat simpler: I only want to have different migration sets for different databases, not varying sets for the same base. Hence, there is no need to modify ActiveRecord::Migrator -- all that is needed is a small change in database.rake so that the user (that would be me) can control where it tells ActiveRecord::Migrator to look for migrations.
Granted, my current minimum-impact solution is perhaps slightly awkward in that it requires a separate environment for the auxiliary database since database.rake relies on RAILS_ENV to load the right environment/database configuration. This is awkward because that environment file is never loaded by the rails app at run-time and so should be left empty (as other settings will not impact the run-time environment anyway).
