对于 ad hoc Rails任务,我们有一些实现备选方案,其中主要似乎是:
script/runner some_useful_thing
和
rake some:other_useful_thing
我更喜欢哪个选项?如果有一个明显的喜欢那么,如果有的话,我应该考虑使用另一个?如果从来没有,那么为什么你认为它仍然存在于没有弃用警告的框架中?
答案 0 :(得分:58)
它们之间的区别在于script/runner
引导Rails而Rake任务没有,除非你通过让任务依赖:environment
来告诉它,如下所示:
task :some_useful_task => :environment do
# do some useful task
end
由于启动Rails很昂贵,如果可以避免它,可能值得跳过。
除此之外,它们大致相同。我使用了两者,但最近我使用script/runner
分别执行了一个脚本。
答案 1 :(得分:10)
FWIW似乎有一些movement away from using script runner支持rake:
更新(2009年4月25日):我建议使用rake任务而不是脚本/运行器来执行重复任务。
另外,作为per this post,你可以使用rake来完成重复任务:
如果我想让它在午夜时分在我的生产数据库上运行,我可能会写一个看起来像这样的cronjob:
0 0 * * * cd / var / www / apps / rails_app /&& / usr / local / bin / rake RAILS_ENV = production utils:send_expire_soon_emails
答案 2 :(得分:9)
根据评论2进行更正。给他们业力!
FWIW - Rails 3.0+更改了在独立脚本中初始化Rails系统的方式。
require File.dirname(__FILE__) + '/config/environment'
如上所述,你也可以这样做:
rails runner script/<script name>
或者将所有代码放在Rake任务中,但是我有很多来自Rails 2的遗留代码;所以我不想立刻沿着这条路走下去。
每个都有其优点和缺点。
答案 3 :(得分:9)
至少可以说,将参数传递给rake任务是一个痛苦的屁股。您需要求助于环境变量或非常讨厌的参数系统,这种参数系统不直观且有很多警告。
如果您的任务需要优雅地处理命令行参数,那么编写脚本是可行的方法。
Luke Francl提到了脚本/跑者启动Rails。这是真的。但是,如果您不想启动rails,那么只需按原样运行脚本,而不使用script / runner。因此,脚本和rake任务之间唯一真正的区别在于它们的美学。选择任何你觉得合适的东西。
我将rake任务用于小任务(一行或两行)。更复杂的东西进入脚本/目录。如果我认为其他开发人员希望代码在一个地方生活而不是另一个地方,那么我将违反此规则。
答案 4 :(得分:5)
我做的一件事就是编写普通的ruby脚本并将它们放在script/maintenance
目录中。
您只需将require '../../config/environment.rb'
放在文件的顶部即可加载导轨并访问所有模型等,然后就可以了。
答案 5 :(得分:3)
在Rails 3.0及其中,config/environment.rb
需要config/application.rb
,这需要config/boot.rb
。
因此,要在Rails 3中加载应用,您仍然只需要environment.rb
答案 6 :(得分:2)
对于一个关闭命令脚本/跑步者可以没问题。对于任何重复的事情,从长远来看,rake任务更容易,如果你忘了它的作用,你会得到一个摘要。
答案 7 :(得分:2)
我得到的印象脚本/跑步者主要是为了定期任务。例如,运行的cron作业:
SomeClass.update_from_web('http://www.sourcefordata.gov/')