Upgrading Rails 2 to Rails 3 is easy!

31 December 2013 by Abhijit Rao No comments

Many people might consider upgrading their Rails 2 apps since even Rails 4 is now released! We too recently upgraded the website of one of our clients – Founder’s Institute from Rails 2 to Rails 3. Migration is sometimes tricky but we outlined a plan for this and we were able to finish up quickly with least bugs. The Rails community maintains incredibly useful documentation whenever they push out major releases. It was extremely helpful for us.

When we started off, first we moved all the code into a Git repo (it was previously on SVN). We decided to break the complexities of migration into smaller, simpler parts and take small steps towards the upgrade.

The app was a fairly standard Rails 2 app with MySQL. To set up the project, the first step was to upgrade all gems. This part was mostly hassle free, thanks to Bundler.

We decided to upgrade all models to be Rails 3 way.

Active Record:

Rails 3 has a new Active Record query engine. It meant Rails now uses the Arel query engine to build SQL queries from Active Record statements. This increased the expressiveness of Queries as well as exposed a simpler API which allows developers to build a Rails compliant ORM. This means seamless integration of your favorite ORMs like Datamapper and Mongoid and is quite a leap towards user’s flexibility.

There are many new finder methods supported by Active Record:

• where(:conditions)
• having(:conditions)
• select
• group
• order
• limit
• offset
• joins
• includes(:include)
• lock
• readonly
• from

Statements like:

are now written as:

The query now looks cleaner and much more readable.

Another cool feature with Active Record is chain ability. Since all finder methods now return an object of Relation, it is easy to chain methods to filter objects and pass conditions while querying.

Active Record now encourages lazy loading of data.

To force early loading, just call the ‘.all’ method on your Active Record query statement. For example,

Usage of named_scopes changes as well. named_scope is now called just scope and it won’t accept options anymore.

is now:

Rails 3 Routes:

Next up was fixing the Rails 2 style routes. Since Rails 3 got a new router, most Rails 2 routes were either deprecated or unsupported. Fixing the routes was easy enough.
This neat little one-liner takes care of migrating most of your routes:

rake rails:upgrade:routes > config/new_routes.rb

Comparison of the new routes with the old ones gives a quick view of syntax changes in the Rails 3 routes.

Most routes like:

are now written as:

Declaring options in routes can be done using the new style:

We no longer need to pass hashes with nil values to specify optional params and they favor RESTfulness. We simply write it like this:

Action mailer:

Action Mailer in Rails 3 has a new syntax and emailers are structured in a more decoupled way.

Mailers are now defined in the app/mailers directory instead of app/models.
Variables accessible in Mailer views are directly set using @my_variable instead of @body[‘my_variable’]

Mails are sent using:
MyMailer.my_mail_method(my_args).deliver
instead of
MyMailer.deliver_my_mail_method(my_args)

The mailer method:

Is now:

The new welcome method looks more like a controller for emails where the instance variables can be accessible in the views.

To avoid having to write the “from” field for every action in your mailer, we can now choose to write:

Agnosticism with jQuery, rSpec, and Data Mapper

Rails 3 has now also adopted Agnosticism with jQuery, rSpec, and Data Mapper.

Rails 3 supports unobtrusive Javascript and one can choose to use Jquery (or any other library/framework) over Prototype which has been the default until now. We chose to use JQuery and then started migrating rails 2 helper methods used in views to be Rails 3 style. Most commonly used expression is the form_remote_tag and it required to be migrated like this:

to

The :remote => true option passed in, tells Rails that the form is going to be submitted using Javascript and we need to write methods to listen to the form submit event.

Unobtrusive javascript removes the ugly inline javascript which appears in the HTML form tag when form_remote_tag is used:

html_safe:

HTML stored as a string in a variable now has to be passed on in the views using the .html_safe method.

Bundler:

Managing dependencies of a Rails app just became so much easier with Rails 3! Bundler allows you to specify versions of gem you want to use in your application. The Gemfile can be used to specify any gems your app needs and bundler will take care of downloading the appropriate version and installing them.

Issues we faced:

Though there were last minute issues that we encountered, most of them were UI fixes where the HTML tags were displayed because of a few missed out .html_safe on strings.

Upgrading Rails apps has been pretty much straightforward; much thanks to the awesome Rails community.

When/why should you upgrade?

1. In this fast paced ever-improving world of software? Almost always!
2. Need more security. Newer versions fix security holes.
3. Code refactoring is needed.
4. Increased maintainability.
5. Help out the community. You can always give feedback on new features in the framework/gems.
6. Using plug-ins and gems that aren’t supported in older versions.
7. Easy to get help from someone with new stuff than old.

Hope this short post helps you with your migration!

Founder’s Institute on upgrading Rails 2 to Rails 3

Abhijit Rao

Follow me on Twitter

Leave a Reply

Your email address will not be published. Required fields are marked *

Subscribe To Our Blog

Get access to proven marketing ideas, latest trends and best practices.

Next up home

Contact

Lets build cool stuff

Share your contact information & we will get in touch!

I want (Tell us more about your dream project)