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!
on 2007-04-11 06:41
on 2007-04-11 10:45
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-