У меня есть задача Rails: я должен использовать скрипт / бегун или грабли? - PullRequest
65 голосов
/ 26 февраля 2009

Для ad hoc Задачи Rails у нас есть несколько вариантов реализации, главной из которых может показаться:

script/runner some_useful_thing

и

rake some:other_useful_thing

Какой вариант мне выбрать? Если есть явный фаворит, то когда, если вообще, я должен рассмотреть использование другого? Если никогда, то почему вы думаете, что он все еще присутствует в структуре без предупреждений об устаревании?

Ответы [ 8 ]

58 голосов
/ 26 февраля 2009

Разница между ними заключается в том, что script/runner загружает Rails, тогда как задача Rake - нет, если вы не указали это, установив задачу в зависимости от :environment, например:

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

Поскольку загрузка Rails стоит дорого, возможно, стоит пропустить, если вы можете избежать этого.

Кроме этого, они примерно эквивалентны. Я использую оба, но в последнее время я использовал script/runner для выполнения скрипта отдельно.

10 голосов
/ 10 мая 2009

FWIW, кажется, есть какое-то движение от использования скриптового бегуна в пользу рейка:

Обновление (25.04.2009): я рекомендую использовать грабельные задачи, а не скрипт / бегун для повторяющихся задач.

Кроме того, как за этот пост вы можете использовать грабли для повторяющихся задач просто отлично:

Если бы я тогда хотел, чтобы это выполнялось ночью в моей производственной базе данных в полночь, я мог бы написать cronjob, который будет выглядеть примерно так:

0 0 * * * cd / var / www / apps / rails_app / && / usr / local / bin / rake RAILS_ENV = использование утилит: send_expire_soon_emails

9 голосов
/ 15 декабря 2012

Передача параметров в грабли - это боль в заднице, если не сказать больше. Вам либо нужно прибегнуть к переменным окружения, либо к очень хакерской системе параметров, которая не интуитивна и имеет множество предостережений.

Если вашей задаче нужно изящно обрабатывать аргументы командной строки, тогда написание сценария - путь.

Люк Франккл упоминает сценарий / бегуна, загружающего Rails. Это правда. Но если вы не хотите загружать рельсы, просто запустите скрипт без скрипта / бегуна. Таким образом, единственное реальное различие между скриптами и граблями - их эстетика. Выберите то, что вам подходит.

Я использую грабли для небольших задач (одна или две строки). Все более сложное входит в каталог script /. Я нарушу это правило, если думаю, что другие разработчики будут ожидать, что код будет жить в одном месте над другим.

9 голосов
/ 30 декабря 2010

Исправлено на основе комментария 2 вниз. Дай им карму!

FWIW - Rails 3.0+ меняет способ инициализации системы Rails в автономном скрипте.

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

Как уже упоминалось выше, вы также можете сделать:

rails runner script/<script name>

Или поместите весь код в задачу Rake, но у меня есть много устаревшего кода из Rails 2; поэтому я не хотел идти по этому пути немедленно.

У каждого есть свои преимущества и недостатки.

5 голосов
/ 26 февраля 2009

Одна вещь, которую я сделал, это просто написал нормальные сценарии ruby ​​и поместил их в каталог script/maintenance.

Все, что вам нужно сделать, чтобы загрузить рельсы и получить доступ ко всем вашим моделям и т. Д., Помещается в require '../../config/environment.rb' вверху файла, и вы ушли.

3 голосов
/ 31 декабря 2010

В Rails 3.0+ для config/environment.rb требуется config/application.rb, для которого требуется config/boot.rb.

Итак, чтобы загрузить приложение в Rails 3, вам по-прежнему требуется только environment.rb

2 голосов
/ 26 февраля 2009

У меня сложилось впечатление, что сценарий / бегун был в основном для периодических задач. Например, задание cron, которое запускается:

SomeClass.update_from_web('http://www.sourcefordata.gov/')
2 голосов
/ 26 февраля 2009

Для однократных команд может подойти скрипт / бегун. Для чего-либо повторного, в долгосрочной перспективе задача сгребания легче и имеет сводку, если вы забудете, что она делает.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...