# New migration method is not dry

**URL:** <https://www.ruby-forum.com/t/new-migration-method-is-not-dry/106284>\
**Category:** Engines\
**Created:** [June 8, 2007, 3:38am UTC](https://www.ruby-forum.com/t/new-migration-method-is-not-dry/106284 "2007-06-08T03:38:53Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![arjackson](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/57b2e6/32.png) [@arjackson](https://www.ruby-forum.com/u/arjackson)\
**Post date:** [June 8, 2007, 3:38am UTC](https://www.ruby-forum.com/t/new-migration-method-is-not-dry/106284/1 "2007-06-08T03:38:53Z")

</div>

I’m confused why the move was made to made to rake plugin\_migration. If  
I have a bunch of apps that use the same engine, now if I change the  
engine schema I need to make sure I add the migrations to each app, with  
plugin\_migration. Can you put back the db:migrate:engines task, and  
give people the option of doing that or plugin\_migration?

-Andrew

---

<div class="post-metadata">

**Author:** ![arjackson](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/57b2e6/32.png) [@arjackson](https://www.ruby-forum.com/u/arjackson)\
**Post date:** [June 8, 2007, 11:00am UTC](https://www.ruby-forum.com/t/new-migration-method-is-not-dry/106284/2 "2007-06-08T11:00:47Z")

</div>

The new mechanism was introduced so that there was a single point of  
truth reflecting the state of your database, which also reflects when  
a plugin was introduced, upgraded or removed. Without integrating  
plugin migrations into the main stream, the developer would have to  
manage these versions themselves, from memory.

I think that _any_ schema change is serious enough to warrant spending  
a bit of individual attention with each application that will be  
affected. I don’t find that running “script/generate plugin\_migration”  
is much of a hardship, and I certainly feel more like I’m in control.

However, if you have many plugins and your schemas are changing  
rapidly, feel free to borrow the old rake task from a previous tagged  
release, and drop it into your application’s Rakefile. Alternatively,  
put it in an empty plugin and add this plugin to each of your  
applications.

James

---

<div class="post-metadata">

**Author:** ![arjackson](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/57b2e6/32.png) [@arjackson](https://www.ruby-forum.com/u/arjackson)\
**Post date:** [June 9, 2007, 5:55am UTC](https://www.ruby-forum.com/t/new-migration-method-is-not-dry/106284/3 "2007-06-09T05:55:03Z")

</div>

After using it a bit, I see your point. What’s complicating things is  
that I have two different apps using the same database by sharing models  
in an engine. So far I’ve been using one app to keep the db up to date,  
the other has no migrations, so if I want to make sure they will each  
run independently I need to do engine migrations in main app on each  
one. I think will designate one app as always necessary and put all the  
migrations there.