Rails 4.2 Overview, Part 2 of 2

This is part 2 in our overview of what is new in Rails 4.2. You can find part 1 here. Part 1 covers ActiveJob, GlobalID and #deliver_later .

In this installment, we will cover Adequate Record, Web Console, and some general thoughts on Rails 4.2

4. Adequate Record

Aaron Patterson has been doing serious performance work on ActiveRecord and these improvements will be included in Rails 4.2. By eliminating a lot of extra work that ActiveRecord was doing and by optimizing for common queries, Aaron has created a version that is twice as fast in many common cases.

In particular, AdequateRecord caches a computed form of your SQL query when using find , find_by , or find_by_foo . This is different than the query result cache that you are familiar with from existing Rails versions. This caches the computation of the query string based on the parameters passed into the finder method.

Currently, more complex queries (e.g. chained #where calls) have not been optimized, so you should prefer find_by over the combination of #where and #last / #first where possible. According to tenderlove, similar caching optimizations for #where and other ActiveRecord query chain methods are coming after AdequateRecord lands in 4.2.

For more information about AdequateRecord, check out Aaron’s closing keynote at RailsConf 2014 and his blog post about AdequateRecord.

5. Web Console

As of Rails 4.2, every development web server also includes an IRB console at /console. This console is available on error pages, which makes debugging your Rails application easier. You can also do this:

<%= console %>

in any view to enable debugging right on the page, in the view’s context. This is useful when a template blows up and you don’t understand why, or the output is different than expected.

If you don’t do any debugging in the browser, give it a try. We find that the tighter development-debugging cycle makes our engineers happier and more productive. Additionally, web console debuggers are the only easy way to jump directly to the location of some common classes of bugs. We’ve been using the better_errors gem to debug Rails applications in the browser for some time, but I’m happy to see an official solution come into Rails core.

General Thoughts

I believe that the number and scope of the new features in 4.2 will make it one of those “big” releases in Rails history. Remember when the asset pipeline was introduced in Rails 3.1, which meant that Rails 3.1 was closer to Rails 4 than it was to Rails 3.0? I think this will be a release like that— more a starting point for Rails 5 than a Rails 4 point release. Rails 4.2 will also be the last 4.X series, with development focus shifting to Rails 5 after the 4.2 stable release.

The Rails 4.2 beta is available. Since this is a beta, not a release candidate, and certainly not a stable version, you would have to be a special kind of crazy to upgrade a “real” application now. However, it is available to play around with, or if you want to start a 4.2 upgrade branch of your app.

We don’t know the release date of the stable version, because we don’t know how fast development will move forward, how long it will take to resolve existing issues with the 4.2 branch, or what new issues will be uncovered between now and the release. In other words, it will be ready when it is ready. That said, Rails 3.1 and 4.0 took four or five months to go from the first beta version to first stable version, so I expect 4.2 stable to land around December 2014 or January 2015.

More Posts by Robert Prehn: