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