Engines and migrations

Rails
1

I’m writing two apps. App_1 uses a subset of models (and thus
migrations) of App_2, and both apps use the same database. At first I
thought engines would be the perfect way to include the models and
migrations in both apps while keeping things DRY, but I’m a little
uneasy as to how the migrations will work.

From my understanding all the models and migrations used in both apps
will go into the engine. Then in App_2, I can call a command to append
all the migrations in the engine onto the migrations already in
db/migrations folder. The problem is App_1 has all the same migrations
except they start at 001, while in App_2 they start at a later version,
which leads to problems migrating.

Do I understand how to use engines correctly? Is there a better
approach to writing multiple apps, while keeping things DRY?

Thanks!

2

There shouldn’t be a problem here. If you had your shared migration in
a plugin, the engines plugin provides the “script/generate
plugin_migration” command to perform these migrations at whatever
point your application is currently at.

In practice, this means that in App_1, you might end up with
RAILS_ROOT/db/migrate/002_migrate_shared_plugin_to_version_1.rb, and
in App_2 you may get RAILS_ROOT/db/migrate/
152_migrate_shared_plugin_to_version_1.rb, but of which should run
fine (presuming that your shared migration doesn’t depend on anything
in the current DB state).

I think the misunderstanding is here: “I can call a command to append
all the migrations in the engine onto the migrations already in db/
migrations folder.” The migrations from the plugin are never appended,
copied or moved. Instead, they are called in a single command within
the RAILS_ROOT/db/migrate generated migration:

Rails.plugins[:shared_plugin].migrate(5)

…which would run all of the migrations (up to version 5, in this
case, but normally this is just the latest version) in the plugin
dynamically.

HTH

James

On Apr 11, 5:41 am, Raymond O’Connor <rails-mailing-l…@andreas-