[ANN] Rails 3.1.4 has been released!

Rails 3.1.4 has been released. This release contains various bug fixes and two important security fixes. All users are recommended to upgrade as soon as possible.

CHANGES

For information regarding the possible vulnerabilities, please see the announcements here and here.

Some highlights from this release are:

  • thrrubyrhino is added to the Gemfile for JRuby users

  • Routing cache improvements

  • Assets group may be skipped with the --skip-sprockets flag

  • Various Ruby 2.0 compatibility fixes

For a comprehensive list, see the commits on github.

[ANN] Rails 3.0.12 has been released!

Rails 3.0.12 has been released. This release contains various bug fixes and two important security fixes. All users are recommended to upgrade as soon as possible.

CHANGES

For information regarding the possible vulnerabilities, please see the announcements here and here.

Some highlights from this release are:

  • require and load will return the value from the superclass

  • ActiveModel confirmation validation fixes

  • Increasing rack dependency

For a comprehensive list, see the commits on github.

Edge Rails: PATCH is the new primary HTTP method for updates

What is PATCH?

The HTTP method PUT means resource creation or replacement at some given URL.

Think files, for example. If you upload a file to S3 at some URL, you want either to create the file at that URL or replace an existing file if there’s one. That is PUT.

Now let’s say a web application has an Invoice model with a paid flag that indicates whether the invoice has been paid. How do you set that flag in a RESTful way? Submitting paid=1 via PUT to /invoices/:id does not conform to HTTP semantics, because such request would not be sending a complete representation of the invoice for replacement.

With the constraints of the methods GET, POST, PUT, DELETE, the traditional answer is to define the paid flag of a given invoice to be a resource by itself. So, you define a route to be able to PUT paid=1 to /invoices/:id/paid. You have to do that because PUT does not allow partial updates to a resource.

Now let’s think about ordinary edit forms in typical Ruby on Rails applications. How many times are we sending a complete representation for replacement? Not always, perhaps we could say that it is even rare in practice that you do so. For example, the conventional created_at and updated_at timestamps normally can’t be set by end-users, though they are often considered to belong to the representation of resources that map to records.

PUT in addition is an idempotent method. You should be able to replay a request as many times as you want and get the same resource, something that sometimes is violated by conventional idioms for creating children resources using nested attributes while updating a parent resource.

There’s nothing theoretical preventing PUT from doing partial updates, but when HTTP was being standarized the replacement semantics were already deployed.

Because of that, the PATCH method was defined in 1995 and standarized later. PATCH is a method that is not safe, nor idempotent, and allows full and partial updates and side-effects on other resources.

In practice, as you see, PATCH suits everyday web programming way better than PUT for updating resources. In Ruby on Rails it corresponds naturally to the way we use update_attributes for updating records.

Thus, PATCH is going to be the primary method for updates in Rails 4.0.

Routing

This is an important change, but we plan to do it in a way that is backwards compatible.

When a resource is declared in config/routes.rb, for example,

resources :users

the action in UsersController to update a user is still update in Rails 4.0.

PUT requests to /users/:id in Rails 4.0 get routed to update as they are today. So, if you have an API that gets real PUT requests it is going to work.

In Rails 4.0, though, the router also routes PATCH requests to /users/:id to the update action.

So, in Rails 4.0 both PUT and PATCH are routed to update.

Forms

Forms of persisted resources:

form_for @user

get “patch” in the hidden field “_method”. The RFC is deliberately vague about the way to represent changes in a PATCH request. Submitting a form is perfectly valid, client and server must simply agree on the accepted ways to update a resource.

Let me emphasize that the “_method” hack is a workaround for the limitations in web browsers. As you probably know Rails routes real HTTP methods. That is, actual PUT, DELETE, and now, PATCH requests are routed to their respective actions.

General availability

PATCH requests are available in all places where the rest of the methods are available today. There is a patch macro for the routes DSL, :via understands the symbol :patch. Tests can issue PATCH requests, request objects respond to patch?, etc. Please see the original commit for details (with an important followup here).

Will my web server understand PATCH?

Yes, it should. I have personally tried Apache, nginx, Phusion Passenger, Unicorn, Thin, and WEBrick. They all understood PATCH requests out of the box.

Also, HTTP clients should be in general able to issue PATCH requests. For example in curl(1) you’d execute:

curl -d'user[name]=wadus' -X PATCH http://localhost:3000/users/1

Credits

We would like to thank David Lee for this contribution and endless patience to keep interested in this even after months of discussion.

Also I would like to highlight the quality of the patch itself. It is excellent: code, tests, all docs revised, comments in code revised. Everything carefully and thoroughly updated. An exemplar patch.

Rails 3.2.0: Faster dev mode & routing, explain queries, tagged logger, store

So we didn’t quite make the December release date as we intended, but hey, why break a good tradition and start hitting release targets now! In any case, your patience has been worldly rewarded young grasshopper: Rails 3.2 is done, baked, tested, and ready to roll!

I’ve been running on 3-2-stable for a few months working on Basecamp Next and it’s been a real treat. The new faster dev mode in particular is a major step up over 3.1.

Do remember that this is the last intended release series that’s going to support Ruby 1.8.7. The master git branch for Rails is now targeting Rails 4.0, which will require Ruby 1.9.3 and above. So now is a great time to start the work on getting your app ready for the current version of Ruby. Let’s not hang around old versions forever and a Sunday like those Python guys :).

There’s a v3.2.0 tag on Github and we of course we still have the 3-2-stable branch as well. You can see all the glorious details of everything that was changed in our CHANGELOG compilation.

For documentation, we have the 3.2 release notes with upgrade instructions, both the API docs and the guides have been generated for 3.2 as well, and there’s a brand new 3.2-compatible version of Agile Web Development with Rails. A smörgåsbord indeed!

Note: If you’re having trouble installing the gems under Ruby 1.8.7, you’ve probably hit a RubyGems bug with YAML that’s been fixed in RubyGems 1.8.15. You can upgrade RubyGems using “gem update —system”.

If you can’t be bothered with the full release notes, here’s a reprint of a few feature highlights from when we did the first release candidate:

Faster dev mode & routing

The most noticeable new feature is that development mode got a ton and a half faster. Inspired by Active Reload, we now only reload classes from files you’ve actually changed. The difference is dramatic on a larger application.

Route recognition also got a bunch faster thanks to the new Journey engine and we made linking much faster as well (especially apparent when you’re having 100+ links on a single page).

Explain queries

We’ve added a quick and easy way to explain quieries generated by ARel. In the console, you can run something like puts Person.active.limit(5).explain and you’ll get the query ARel produces explained (so you can easily see whether its using the right indexes). There’s even a default threshold in development mode where if a query takes more than half a second to run, it’s automatically explained inline — how about that!

Tagged logger

When you’re running a multi-user, multi-account application, it’s a great help to be able to filter the log by who did what. Enter the TaggedLogging wrapper. It works like this:

Logger = ActiveSupport::TaggedLogging.new(Logger.new(STDOUT))
Logger.tagged("BCX") { Logger.info "Stuff" } # Logs "[BCX] Stuff"
Logger.tagged("BCX") do
  Logger.tagged("Jason") do
    Logger.info "Stuff" # Logs "\[BCX\] \[Jason\] Stuff"
  end
end

Active Record Store

Key/value stores are great, but it’s not always you want to go the whole honking way just for a little variable-key action. Enter the Active Record Store:

class User < ActiveRecord::Base
  store :settings, accessors: [ :color, :homepage ]
end
 
u = User.new(color: 'black', homepage: '37signals.com')
u.color                          # Accessor stored attribute
u.settings[:country] = 'Denmark' # Any attribute, even if not specified with an accessor

Rails 3.2.0.rc2 has been released!

Hi everyone,

Rails 3.2.0.rc2 has been released!

What to update in your apps

  • Update your Gemfile to depend on rails ~> 3.2.0.rc2
  • Update your Gemfile to depend on sass-rails ~> 3.2.3
  • Start moving any remaining Rails 2.3-style vendor/plugins/*. These are finally deprecated!

Extract your vendor/plugins to their own gems and bundle them in your Gemfile. If they’re tiny, not worthy of the own gem, fold it into your app as lib/myplugin/* and config/initializers/myplugin.rb.

Changes since RC1

Action Mailer

  • No changes

Action Pack

  • Add font_path helper method Santiago Pastorino

  • Depends on rack ~> 1.4.0 Santiago Pastorino

  • Add :gzip option to caches_page. The default option can be configured globally using page_cache_compression Andrey Sitnik

Active Model

  • No changes

Active Record

  • No changes

Active Resource

  • No changes

Active Support

  • ActiveSupport::Base64 is deprecated in favor of ::Base64. Sergey Nartimov

Railties

  • Rails 2.3-style plugins in vendor/plugins are deprecated and will be removed in Rails 4.0. Move them out of vendor/plugins and bundle them in your Gemfile, or fold them in to your app as lib/myplugin/* and config/initializers/myplugin.rb. Santiago Pastorino

  • Guides are available as a single .mobi for the Kindle and free Kindle readers apps. Michael Pearson & Xavier Noria

  • Allow scaffold/model/migration generators to accept a “index” and “uniq” modifiers, as in: “tracking_id:integer:uniq” in order to generate (unique) indexes. Some types also accept custom options, for instance, you can specify the precision and scale for decimals as “price:decimal{7,2}”. Dmitrii Samoilov

Gem checksums

  • MD5 (actionmailer-3.2.0.rc2.gem) = 118c83b2cddaa935d1de7534cfb6c810
  • MD5 (actionpack-3.2.0.rc2.gem) = 6b18851bc26d5c8958672f27adda05ca
  • MD5 (activemodel-3.2.0.rc2.gem) = d82f4eed949dcff17f8bf2aed806679a
  • MD5 (activerecord-3.2.0.rc2.gem) = d07806fd5fc464f960200d20ceb2193a
  • MD5 (activeresource-3.2.0.rc2.gem) = f51af240ff4623b0b6f8a4293ffa50dc
  • MD5 (activesupport-3.2.0.rc2.gem) = 01380240c12e0380c9e61c97dd45f2f1
  • MD5 (rails-3.2.0.rc2.gem) = 134f923f7d821f514abf6bdf4af62ca7
  • MD5 (railties-3.2.0.rc2.gem) = 4b3ac0f9c5da16b90a1875e8199253d2

You can find an exhaustive list of changes on github. Along with the closed issues marked for v3.2.0.

You can also see issues we haven’t closed yet.

Thanks to everyone!

Rails/master is now 4.0.0.beta

The forthcoming 3.2.x release series will be the last branch of Rails that supports Ruby 1.8.7. There’s a new 3-2-stable branch in git to track the changes we need until 3.2.0 final is release and for managing point releases after that.

So for now you should stop floating on rails/master if your application is not compatible with Ruby 1.9.3. We have updated the version numbers to indicate this backwards incompatibility to be 4.0.0.beta. This doesn’t mean that 4.0 is anywhere close to being released, mind you. We’re simply doing this now because we’re dropping support for Ruby 1.8.7 in rails/master and people should know what’s up.

Major versions of Rails has been on about 2-year release cycle since 1.0 (released in 2005, followed by 2.0 in 2007, followed by 3.0 in 2010) and we intend to continue this pattern. The current internal target for Rails 4.0 is sometime in the Summer of 2012 — but we have blown every major release estimate in the past, so don’t bet your farm on it.

There’s not a lot of details about what we’re going to include in Rails 4.0 yet as the primary purpose for bumping the major version number is to drop Ruby 1.8.7 support. But unlike Rails 3.0, we intend for it to be a much smoother transition. The intention is not for this to be a REWRITE EVERYTHING release in the same way 3.0 was to some extent.

But we’re getting ahead of ourselves. First mission is to get Rails 3.2 out!

Rails 3.2 RC1: Faster dev mode & routing, explain queries, tagged logger, store

Once you’ve boarded the Rails train, you just know that every stop along the way is going to be a good time. This release candidate is no different and we’ve packed it with loving goodies without making upgrading a hassle.

Faster dev mode & routing

The most noticeable new feature is that development mode got a ton and a half faster. Inspired by Active Reload, we now only reload classes from files you’ve actually changed. The difference is dramatic on a larger application.

Route recognition also got a bunch faster thanks to the new Journey engine and we made linking much faster as well (especially apparent when you’re having 100+ links on a single page).

Explain queries

We’ve added a quick and easy way to explain quieries generated by ARel. In the console, you can run something like puts Person.active.limit(5).explain and you’ll get the query ARel produces explained (so you can easily see whether its using the right indexes). There’s even a default threshold in development mode where if a query takes more than half a second to run, it’s automatically explained inline — how about that!

Tagged logger

When you’re running a multi-user, multi-account application, it’s a great help to be able to filter the log by who did what. Enter the TaggedLogging wrapper. It works like this:

Logger = ActiveSupport::TaggedLogging.new(Logger.new(STDOUT)) Logger.tagged(“BCX”) { Logger.info “Stuff” } # Logs “[BCX] Stuff” Logger.tagged(“BCX”) do Logger.tagged(“Jason”) do Logger.info “Stuff” # Logs “\[BCX\] \[Jason\] Stuff” end end

Active Record Store

Key/value stores are great, but it’s not always you want to go the whole honking way just for a little variable-key action. Enter the Active Record Store:

class User < ActiveRecord::Base store :settings, accessors: [ :color, :homepage ] end u = User.new(color: ‘black’, homepage: ‘37signals.com’) u.color # Accessor stored attribute u.settings[:country] = ‘Denmark’ # Any attribute, even if not specified with an accessor

These are just a few of the highlights. The full release notes detail every loving change.

Given that this is a release candidate, we’re ever so eager to hear your feedback. We hope it’ll be a quick RC phase, but please do spoil that plan by reporting bugs.

As always, you install a release candidate by doing gem install rails --pre.

What's new in Edge Rails: EXPLAIN

There are some new features related to EXPLAIN in the forthcoming Ruby on Rails 3.2 we’d like to share:

  • Running EXPLAIN manually
  • Automatic EXPLAIN for slow queries
  • Silencing automatic EXPLAIN

As of this writing they are available for the adapters sqlite3, mysql2, and postgresql.

Running EXPLAIN Manually

You can now run EXPLAIN on the SQL generated by a relation this way:

User.where(:id => 1).joins(:posts).explain

The result of that method call is a string that carefully imitates the output of database shells. For example, under MySQL you get something similar to

EXPLAIN for: SELECT `users`.* FROM `users` INNER JOIN `posts` ON `posts`.`user_id` = `users`.`id` WHERE `users`.`id` = 1
+----+-------------+-------+-------+---------------+---------+---------+-------+------+-------------+
| id | select_type | table | type  | possible_keys | key     | key_len | ref   | rows | Extra       |
+----+-------------+-------+-------+---------------+---------+---------+-------+------+-------------+
|  1 | SIMPLE      | users | const | PRIMARY       | PRIMARY | 4       | const |    1 |             |
|  1 | SIMPLE      | posts | ALL   | NULL          | NULL    | NULL    | NULL  |    1 | Using where |
+----+-------------+-------+-------+---------------+---------+---------+-------+------+-------------+
2 rows in set (0.00 sec)

and under PostgreSQL the same call yields something like

EXPLAIN for: SELECT "users".* FROM "users" INNER JOIN "posts" ON "posts"."user_id" = "users"."id" WHERE "users"."id" = 1
                                  QUERY PLAN
------------------------------------------------------------------------------
 Nested Loop Left Join  (cost=0.00..37.24 rows=8 width=0)
   Join Filter: (posts.user_id = users.id)
   ->  Index Scan using users_pkey on users  (cost=0.00..8.27 rows=1 width=4)
         Index Cond: (id = 1)
   ->  Seq Scan on posts  (cost=0.00..28.88 rows=8 width=4)
         Filter: (posts.user_id = 1)
(6 rows)

Please note that explain runs the query or queries and asks the database for their respective query plan afterwards. This is because due to eager loading a relation may trigger several queries to fetch the records and their associations, and in such cases some queries need the result of the previous ones.

If the relation triggers several queries the method still returns a single string with all the query plans. This is an output meant for human consumption so we preferred to present everything as a string in a format which is familiar right away rather than a structure.

Automatic EXPLAIN For Slow Queries

Rails 3.2 has the ability to help in detecting slow queries.

New applications get

config.active_record.auto_explain_threshold_in_seconds = 0.5

in config/environments/development.rb. Active Record monitors queries and if they take more than that threshold their query plan will be logged using warn.

That works for anything running find_by_sql (which is almost everything, since most of Active Record ends up calling that method). In the particular case of relations, the threshold is compared against the total time needed to fetch the records, not against the time taken by each individual query. Because conceptually we are concerned with the cost of the call

User.where(:id => 1).joins(:posts).explain

rather than the cost of the different queries that call may trigger due to the implementation.

By default the threshold is nil in the test and production environments, which means the feature is disabled.

The value of that parameter is nil also if the threshold is not set, so existing applications will need to add it by hand if they migrate to 3.2 to be able to enable automatic EXPLAIN.

Silencing Automatic EXPLAIN

With automatic EXPLAIN enabled, it could still be the case that some queries are just slow and you know they have to be. For example, a heavyweight report in the backoffice.

The macro silence_auto_explain allows you to avoid having EXPLAIN run repeatedly in those areas of code:

ActiveRecord::Base.silence_auto_explain do
  # no automatic EXPLAIN here
end

Interpreting Query Plans

The interpretation of the query plans is another topic, these are some pointers:

Happy debugging!

Rails 3.1.3 has been released

Rails 3.1.3 has been released. This release mainly contains fixes for regressions that popped up in 3.1.2.

Changes

Action Pack:

  • Downgrade sprockets to ~> 2.0.3. Using 2.1.0 caused regressions.

  • Fix using translate helper with a html translation which uses the :count option for pluralization.

    Jon Leighton

Active Record:

  • Perf fix: If we’re deleting all records in an association, don’t add a IN(..) clause to the query. GH 3672

    Jon Leighton

  • Fix bug with referencing other mysql databases in set_table_name. GH 3690

  • Fix performance bug with mysql databases on a server with lots of other databses. GH 3678

    Christos Zisopoulos and Kenny J

Railties:

  • New apps should be generated with a sass-rails dependency of 3.1.5, not 3.1.5.rc.2

As ever, you can see a full list of changes on Github.