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 H. 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.
–
Sava C.
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 H. 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.
–
Sava C.
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
On 10/31/06, Sava C. [email protected] wrote:
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.
–
- J *
~