New migration method is not dry

Rails Engines
1

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

2

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

3

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.