Support for alternate migrations location

[Jacob-61]

Hi all,

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
        ...

datawarehouse_development:
        migrations: datawarehouse      <-- alternate location for migrations
        adapter: postgresql
        database: dw_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:

   RAILS_ENV=datawarehouse_development rake db:migrate

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?


Cheers
Jacob Lauemøller



--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group.
To post to this group, send email to rubyonrails-core@...
To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@...
For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en
-~----------~----~----~----~------~----~------~--~---

[Gaspard Bucher]

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.

http://github.com/zena/zena/blob/master/lib/zena/migrator.rb

Gaspard

On Tue, Nov 10, 2009 at 7:04 PM, Jacob Lauemøller
<jacob.lauemoeller@...> wrote:

>
> Hi all,
>
> 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
>        ...
>
> datawarehouse_development:
>        migrations: datawarehouse      <-- alternate location for migrations
>        adapter: postgresql
>        database: dw_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:
>
>   RAILS_ENV=datawarehouse_development rake db:migrate
>
> 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?
>
>
> Cheers
> Jacob Lauemøller
>
>
>
> >
>

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group.
To post to this group, send email to rubyonrails-core@...
To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@...
For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en
-~----------~----~----~----~------~----~------~--~---

[Jacob-61]

Gaspard,

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).

Regards,
Jacob


On 10/11/2009, at 19.12, Gaspard Bucher wrote:

>
> 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.
>
> http://github.com/zena/zena/blob/master/lib/zena/migrator.rb
>
> Gaspard
>
> On Tue, Nov 10, 2009 at 7:04 PM, Jacob Lauemøller
> <jacob.lauemoeller@...> wrote:
>>
>> Hi all,
>>
>> 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
>>        ...
>>
>> datawarehouse_development:
>>        migrations: datawarehouse      <-- alternate location for migrations
>>        adapter: postgresql
>>        database: dw_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:
>>
>>   RAILS_ENV=datawarehouse_development rake db:migrate
>>
>> 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?
>>
>>
>> Cheers
>> Jacob Lauemøller
>>
>>
>>
>>>
>>
>
> >

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group.
To post to this group, send email to rubyonrails-core@...
To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@...
For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en
-~----------~----~----~----~------~----~------~--~---