rake db:migrate - targeting a specific <migration>.rb file ???

Hi,

Is it possible to target a once off migration file with “rake db:migrate”?

Like is there a way to do something like: rake db:migrate vendor/plugins/pluginX/migrationfile.rb ???

Tks

Greg Hauptmann wrote:

Hi,

Is it possible to target a once off migration file with "rake db:migrate"?

Like is there a way to do something like: rake db:migrate vendor/plugins/pluginX/migrationfile.rb ???

No. Your plugin has to define its own task that may call db:migrate from within itself to target plugin's migrations. It's a good practice to wrap your plugin's tasks in a namespace named as the plugin.

Tks Sava - don’t fully understand what you meant…I’ll lookup the plugin doco. I think you’re suggesting for plugins there is a separate command to call for it’s migrations that isn’t triggered by a normal “rake db:migrate” call, however perhaps I’m wrong.

Greg Hauptmann wrote:

Tks Sava - don't fully understand what you meant...I'll lookup the plugin doco. I think you're suggesting for plugins there is a separate command to call for it's migrations that isn't triggered by a normal "rake db:migrate" call, however perhaps I'm wrong.

You think of the migration as one-off, but what will happen if you deploy it and later decide to modify database stuff it creates? You'll have to add a new migration - how your application will know what version of your plugin's db schema it is using? There is no standard way in Rails for changing database schema from within a plugin. Anyhow, if you need migrations in a plugin, take a look at Rails Engines - they're designed for such things. Keep in mind though that engines are a bit of unwanted child in Rails world - read documentation carefully.

"Unwanted child" is a bit strong; the engines plugin enables a degree of reuse which DHH doesn't feel is necessary for the software *he* wants to use Rails to write. Some people agree, others don't, but the choice is there, which is the important part.

Answering the original question, you need to be careful when introducing migrations into plugins. Implementing the mechanism isn't too hard (feel free to use the implementation in engines, or just install the engines plugin along side yours to get it for free), but more difficult is managing the introduction of migrations at an unknown point in your schema's life.

Because a plugin can technically be added to an application at any point during its development, you need to be careful that the schema modifications your plugin makes don't rely on (or interfere directly) with application-specific schema details. Worth thinking hard about, and the engines mechanism for sharing schema will likely change in the future to better manage this.

maybe for the moment I’ll manually copy my plugin database migrations into the application proper, hence putting it in as just another migration for the application with it’s own migration number etc. If there are any plugin changes I’ll no doubt have to integrate these into the application proper anyway so adjusting the migrations will be just part of this

btw - James, with engines you can also leverage the fact you can drop a copy of a engine plugin *.rb file directly into your application area and that any class methods here will add (or override) methods from that specified by the same file in the vendor plugin area no?

Cheers