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 On 6/8/07, Andrew Roth <[EMAIL PROTECTED]> wrote: > 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 > > -- > Posted via http://www.ruby-forum.com/. > _______________________________________________ > engine-users mailing list > [email protected] > http://lists.rails-engines.org/listinfo.cgi/engine-users-rails-engines.org > -- * J * ~ _______________________________________________ engine-users mailing list [email protected] http://lists.rails-engines.org/listinfo.cgi/engine-users-rails-engines.org
