71

对于特定的 Rails 任务，我们有一些实现替代方案，其中主要的似乎是：

script/runner some_useful_thing

和：

rake some:other_useful_thing

我应该更喜欢哪个选项？如果有一个明确的最爱，那么我应该在什么时候（如果有的话）考虑使用另一个？如果从来没有，那么您为什么认为它仍然存在于框架中而没有弃用警告？

4

8 回答 8

63

它们之间的区别在于script/runner启动 Rails 而 Rake 任务不会，除非您通过使任务依赖来告诉它:environment，如下所示：

task :some_useful_task => :environment do
  # do some useful task
end

由于引导 Rails 的成本很高，如果可以避免的话，可能值得跳过。

除此之外，它们大致相等。我两者都使用，但最近我script/runner更多地使用单独执行脚本。

于 2009-02-26T18:49:07.127 回答
10

FWIW 似乎有一些远离使用脚本运行器来支持 rake 的运动：

更新（2009 年 4 月 25 日）：我建议使用 rake 任务而不是脚本/运行程序来执行重复任务。

此外，根据这篇文章，您可以将 rake 用于重复性任务就好了：

如果我希望它每晚在午夜在我的生产数据库上运行，我可能会编写一个看起来像这样的 cronjob：

0 0 * * * cd /var/www/apps/rails_app/ && /usr/local/bin/rake RAILS_ENV=production utils:send_expire_soon_emails

于 2009-05-10T19:01:28.410 回答
10

至少可以说，将参数传递给 rake 任务是一件让人头疼的事情。您要么需要使用环境变量，要么需要使用不直观且有很多警告的非常老套的参数系统。

如果您的任务需要优雅地处理命令行参数，那么编写脚本是您的最佳选择。

Luke Francl 提到了启动 Rails 的脚本/运行程序。确实如此。但是，如果您不想启动 rails，那么只需按原样运行脚本，无需脚本/运行器。因此，脚本和 rake 任务之间唯一真正的区别是它们的美学。选择任何你觉得合适的东西。

我将 rake 任务用于小任务（一两行）。任何更复杂的东西都进入 script/ 目录。如果我认为其他开发人员会期望代码位于一个地方而不是另一个地方，我将打破这条规则。

于 2012-12-15T00:58:07.220 回答
9

根据评论 2 更正。给他们业力！

FWIW - Rails 3.0+ 改变了您在独立脚本中初始化 Rails 系统的方式。

require File.dirname(__FILE__) + '/config/environment'

如上所述，您还可以执行以下操作：

rails runner script/<script name>

或者将所有代码放在 Rake 任务中，但我有很多来自 Rails 2 的遗留代码；所以我不想立即走这条路。

每个都有其优点和缺点。

于 2010-12-29T22:13:22.330 回答
5

我所做的一件事就是编写普通的 ruby​​ 脚本并将它们放在script/maintenance目录中。

加载rails和访问所有模型等所需要做的一切都放在require '../../config/environment.rb'文件的顶部，然后你就走了。

于 2009-02-26T19:35:44.643 回答
3

对于一次性命令脚本/运行程序可以很好。对于重复的任何内容，从长远来看，rake 任务更容易，并且如果您忘记了它的作用，它会有一个摘要。

于 2009-02-26T17:36:33.743 回答
3

在 Rails 3.0+ 中，config/environment.rb需要config/application.rb， 需要config/boot.rb.

因此，要在 Rails 3 中加载应用程序，您仍然只需要要求environment.rb

于 2010-12-31T17:44:30.000 回答
2

我得到的印象脚本/运行器主要用于定期任务。例如，一个运行的 cron 作业：

SomeClass.update_from_web('http://www.sourcefordata.gov/')
于 2009-02-26T18:03:38.310 回答