# Rake db:migrate - targeting a specific \<migration\>.rb file?

**URL:** <https://www.ruby-forum.com/t/rake-db-migrate-targeting-a-specific-migration-rb-file/74026>\
**Category:** Rails\
**Created:** [October 29, 2006, 8:08am UTC](https://www.ruby-forum.com/t/rake-db-migrate-targeting-a-specific-migration-rb-file/74026 "2006-10-29T08:08:33Z")\
**Posts on this page:** 6\
**Page:** 1

<div class="post-metadata">

**Author:** ![greg](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/g/71c47a/32.png) [@greg](https://www.ruby-forum.com/u/greg)\
**Post date:** [October 29, 2006, 8:08am UTC](https://www.ruby-forum.com/t/rake-db-migrate-targeting-a-specific-migration-rb-file/74026/1 "2006-10-29T08:08:33Z")

</div>

Hi,

Is it possible to target a once off migration file with “rake  
db:migrate”?

Like is there a way to do something like: rake db:migrate  
vendor/plugins/pluginX/migrationfile.rb ???

Tks

---

<div class="post-metadata">

**Author:** ![greg](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/g/71c47a/32.png) [@greg](https://www.ruby-forum.com/u/greg)\
**Post date:** [November 7, 2006, 10:47am UTC](https://www.ruby-forum.com/t/rake-db-migrate-targeting-a-specific-migration-rb-file/74026/2 "2006-11-07T10:47:11Z")

</div>

Greg H. wrote:

> Hi,
> 
> Is it possible to target a once off migration file with “rake db:migrate”?
> 
> Like is there a way to do something like: rake db:migrate  
> vendor/plugins/pluginX/migrationfile.rb ???

No. Your plugin has to define its own task that may call db:migrate from  
within  
itself to target plugin’s migrations. It’s a good practice to wrap your  
plugin’s  
tasks in a namespace named as the plugin.

–  
Sava C.

---

<div class="post-metadata">

**Author:** ![greg](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/g/71c47a/32.png) [@greg](https://www.ruby-forum.com/u/greg)\
**Post date:** [November 7, 2006, 10:47am UTC](https://www.ruby-forum.com/t/rake-db-migrate-targeting-a-specific-migration-rb-file/74026/3 "2006-11-07T10:47:12Z")

</div>

Tks Sava - don’t fully understand what you meant…I’ll lookup the  
plugin  
doco. I think you’re suggesting for plugins there is a separate command  
to  
call for it’s migrations that isn’t triggered by a normal “rake  
db:migrate”  
call, however perhaps I’m wrong.

---

<div class="post-metadata">

**Author:** ![greg](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/g/71c47a/32.png) [@greg](https://www.ruby-forum.com/u/greg)\
**Post date:** [November 7, 2006, 10:48am UTC](https://www.ruby-forum.com/t/rake-db-migrate-targeting-a-specific-migration-rb-file/74026/4 "2006-11-07T10:48:44Z")

</div>

Greg H. wrote:

> Tks Sava - don’t fully understand what you meant…I’ll lookup the plugin  
> doco. I think you’re suggesting for plugins there is a separate command to  
> call for it’s migrations that isn’t triggered by a normal “rake db:migrate”  
> call, however perhaps I’m wrong.

You think of the migration as one-off, but what will happen if you  
deploy it and  
later decide to modify database stuff it creates? You’ll have to add a  
new  
migration - how your application will know what version of your plugin’s  
db  
schema it is using? There is no standard way in Rails for changing  
database  
schema from within a plugin. Anyhow, if you need migrations in a plugin,  
take a  
look at Rails Engines - they’re designed for such things. Keep in mind  
though  
that engines are a bit of unwanted child in Rails world - read  
documentation  
carefully.

–  
Sava C.

---

<div class="post-metadata">

**Author:** ![greg](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/g/71c47a/32.png) [@greg](https://www.ruby-forum.com/u/greg)\
**Post date:** [November 7, 2006, 10:50am UTC](https://www.ruby-forum.com/t/rake-db-migrate-targeting-a-specific-migration-rb-file/74026/5 "2006-11-07T10:50:00Z")

</div>

maybe for the moment I’ll manually copy my plugin database migrations  
into  
the application proper, hence putting it in as just another migration  
for  
the application with it’s own migration number etc. If there are any  
plugin  
changes I’ll no doubt have to integrate these into the application  
proper  
anyway so adjusting the migrations will be just part of this

btw - James, with engines you can also leverage the fact you can drop a  
copy  
of a engine plugin \*.rb file directly into your application area and  
that  
any class methods here will add (or override) methods from that  
specified by  
the same file in the vendor plugin area no?

Cheers

---

<div class="post-metadata">

**Author:** ![greg](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/g/71c47a/32.png) [@greg](https://www.ruby-forum.com/u/greg)\
**Post date:** [November 7, 2006, 10:49am UTC](https://www.ruby-forum.com/t/rake-db-migrate-targeting-a-specific-migration-rb-file/74026/6 "2006-11-07T10:49:01Z")

</div>

On 10/31/06, Sava C. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote:

> Anyhow, if you need migrations in a plugin, take a  
> look at Rails Engines - they’re designed for such things. Keep in mind though  
> that engines are a bit of unwanted child in Rails world - read documentation  
> carefully.

“Unwanted child” is a bit strong; the engines plugin enables a degree  
of reuse which DHH doesn’t feel is necessary for the software _he_  
wants to use Rails to write. Some people agree, others don’t, but the  
choice is there, which is the important part.

Answering the original question, you need to be careful when  
introducing migrations into plugins. Implementing the mechanism isn’t  
too hard (feel free to use the implementation in engines, or just  
install the engines plugin along side yours to get it for free), but  
more difficult is managing the introduction of migrations at an  
unknown point in your schema’s life.

Because a plugin can technically be added to an application at any  
point during its development, you need to be careful that the schema  
modifications your plugin makes don’t rely on (or interfere directly)  
with application-specific schema details. Worth thinking hard about,  
and the engines mechanism for sharing schema will likely change in the  
future to better manage this.

–

- J \*  
~
