Какие важные различия существуют между средой разработки и производства Rails? - PullRequest
Новая
       8

Какие важные различия существуют между средой разработки и производства Rails?

2 голосов
/ 19 января 2011

Сегодня я столкнулся с ужасной проблемой из-за различий между средой производства и разработки Rail.Рассмотрим код: 

"select * from subscription_plans where affiliate_id is null or affiliate_id = #{@subscription_plan.affiliate.id rescue 0};"

Партнеров с идентификатором 0 никогда не будет, поэтому, если @ subscription_plan.affiliate равен nill, я ожидал, что запрос вернет только планы подписки без партнера.Прекрасно работает в среде разработки, потому что nil.id выдает ошибку (при условии, что он дает некоторое сообщение об этом, по ошибке должно быть 4).Проблема в том, что я отправил этот код на свой рабочий сервер, и планы подписки с affiliate_id 4 начали появляться все время.В работе nil.id не выдает ошибку, а просто возвращает 4. Боже, спасибо rails.

Все это, чтобы спросить, что еще я должен знать как разработчик Rails?В частности, существуют ли другие различия между средами, которые потенциально могут вызвать проблемы?

Ответы [ 2 ]

5 голосов
/ 19 января 2011

Все, что отличается между производством и разработкой, настраивается. Если вы хотите, чтобы nil в производстве, добавьте это в ваш production.rb файл: 

# Log error messages when you accidentally call methods on nil.
config.whiny_nils = true

Просто посмотрите на ваши config/environments/production.rb и config/environments/development.rb файлы и прочитайте комментарии и документацию по используемым методам / свойствам. Вне моей головы, вот некоторые различия:

  1. Код не перезагружается в рабочей среде, поэтому, если у вас есть какие-либо константы, для которых установлено значение Time.now или 1.day.ago, или что-то еще в разработке, которая работает должным образом, они не будут работать в рабочей среде.
  2. debug сообщения журнала уровня игнорируются при производстве.
  3. кэширование включено только в рабочей среде
  4. подробные сообщения об ошибках доступны только в разработке (хотя они заносятся в журнал rails)

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

Также краткая критика кода:

  1. Шаблон rescue foo, как правило, плохая идея. Допустимые ошибки, которые могли возникнуть, будут игнорироваться.
  2. Используйте SQL-интерполяцию ActiveRecord для добавления динамических значений в строку SQL, не используйте #{}.
0 голосов
/ 19 января 2011

Во-первых, я не уверен, что это проблема производства против разработки.Используете ли вы разные версии Ruby в каждой среде?Если так, то я бы порекомендовал использовать RVM для использования одной и той же версии для обоих.

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

Наконец, ваш код должен быть реорганизован для лучшего использования ActiveRecord: 

class SubscriptionPlan < ActiveRecord::Base
  belongs_to :affiliate
end

Использование... 

@subscriptions = SubscriptionPlan.find(:all, :include => :affiliate)

Тогда вы можете сделать что-то вроде: 

@subscription.first.affiliate
...