CODEWITHSUNDEEP
ruby-on-railsactiverecorddevelopment-environment
tybro0103
tybro0103

Reputation: 49693

What important differences are there between Rails' development and production environments?

I experienced a horrible problem today as a result of differences between Rail's production and development environments. Consider the code:

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

There will never be any affiliates with an id of 0, so if @subscription_plan.affiliate is nill I expected the query to return only subscription plans without an affiliate. Works great in development environment because nil.id throws an error (provided it does give some message about it should mistakenly be 4). Problem is, I pushed that code live to my production server and subscription plans with an affiliate_id of 4 started showing up all over. In production, nil.id doesn't throw an error, but rather simply returns 4. Geez, thanks rails.

All that to ask, what other things should I be aware of as a Rails developer? In particular, are there other differences between environments that could potentially cause problems?

Upvotes: 2

Views: 4031

Answers (2)

Peter Brown
Peter Brown

Reputation: 51697

First, I'm not convinced this is an issue with Production vs Development. Are you using different versions of Ruby in each environment? If so, then I would recommend using RVM to use the same version for both.

Second, you should have a staging environment which mirrors your production server. It's really bad practice to push to production if you haven't tested on an identical clone.

Last, your code should be refactored to make better use of ActiveRecord:

class SubscriptionPlan < ActiveRecord::Base
  belongs_to :affiliate
end

Usage...

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

Then you can do something like: 

@subscription.first.affiliate

Upvotes: 0

Brian Donovan
Brian Donovan

Reputation: 8390

Everything that's different between production and development is configurable. If you want whiny nils in production, add this to your production.rb file:

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

Just look at your config/environments/production.rb and config/environments/development.rb files and read the comments and documentation on the methods/properties being used. Off the top of my head, here are some differences:

  1. Code is not reloaded in production, so if you have any constants that are set to Time.now or 1.day.ago or whatever in development that work as expected, they won't work in production.
  2. debug level log messages are ignored in production.
  3. caching is enabled only in production
  4. verbose error messages are only available in development (though they are logged to the rails log)

There are more, probably, but if you just check out the config files you should get a good idea of what the differences are.

Also, a brief code critique:

  1. The rescue foo pattern is generally a bad idea. Legitimate errors that may have been raised will be ignored.
  2. Use ActiveRecord SQL interpolation to add dynamic values to a SQL string, don't use #{}.

Upvotes: 5

Related Questions