Upgrading to Rails 5
We recently completed our upgrade from Rails 4.2 to Rails 5. 🎉. Along the way we, encountered some breaking changes not covered in the upgrade guide and wanted to share our experience in case others run into the same issues.
ActiveRecord::Relation no longer blanket delegates to array
Prior to Rails 5, all array methods would work on Relation except for a hard-coded blacklist as the there was a generic delegation to the underlying array. The blacklist existed to block mutating methods such as compact! and flatten! that do not make sense for a Relation. Rails 5 changes the delegation to be a whitelist, causing methods such as combination and to_csv to fail with NoMethodError
More subtly, a separate pull request changes the array delegation from delegate *array_methods, to: :to_a to delegate *array_methods, to: :records. As a result, calling an array method on a Relation will call that method directly on the underlying records instead of making a copy first with to_a, causing bugs if concurrently modifying a collection.
# assume author has articles with ids 1, 2, 3, and 4
author.articles.each do |article|
author.articles.destroy!(article) if [2,3].include?(article.id)
end# in Rails 4, .each creates a copy of the records so it behaves as desired, removing articles 2 and 3
author.articles.count == 2# in Rails 5, .each directly modifies the records, causing concurrent modification and skipping article 3
author.articles.count == 3
SerializableHash errors for non-existing methods
In Rails 4 and earlier, calling a non-existing method in, for example, as_json would silently give null for the requested key:
class Author < ActiveRecord::Base
def as_json(options = {})
options[:methods] = [:does_not_exist]
super(options)
end
endAuthor.new.as_json == {does_not_exist: nil}
This unexpected behavior was updated to raise a NoMethodError
No more implicit to_i when making queries with enums
A common mistake I have seen among Ruby on Rails developers is to write a SQL query with an enum string instead of the underlying integer:
class Author < ActiveRecord::Base
enum genre {
fiction: 0,
nonfiction: 1
}
endAuthor.where(genre: 'nonfiction') # Whoops, should have done Author.where(genre: 1)
This error can be very hard to track down in Rails 4, as the generated SQL query tries to convert the genre into an integer. In ruby, to_i returns 0 if it fails to parse the string (e.g. 'a'.to_i == 0) so the above query would be SELECT * FROM "authors" WHERE "authors"."genre" = 0, the exact opposite of the intended behavior! Rails 5, as a more grown-up framework, ops for prepared statements instead, generating SELECT * FROM "authors" WHERE "authors"."genre" = $1, [["genre", "nonfiction"]]. In most SQL adapters, this prepared query will noisily error about type mismatches.
Parameter deep munging removed
Because of potential security vulnerabilities in Rails 3 and earlier, ActionController munged all empty arrays to nil. For example, a post request with params {author_ids: []} would be converted to {author_ids: nil} when accessed in a controller. Rails 4 removed the security vulnerability ( Author.where(name: []) generates SELECT * FROM authors WHERE 1=0) but left the munging. Rails 5 removes the munging, requiring changing any potential nil? checks to present? checks instead.
protect_from_forgery changed to prepend: false
One of the first things to add to any new ApplicationController is protect_from_forgery which adds protects against CSRF by verifying the authenticity token sent with every request. Before Rails 5, protect_from_forgery inserted itself at the beginning of the action callback chain so it would run before any other before_action even if declared afterward. This prepend behavior was removed in Rails 5, making protect_from_forgery behave like any other before_action. While a minor change, this will cause apps using Devise to fail if protect_from_forgery comes after authenticate_user
Conclusion
Rails 5 was definitely a worthwhile upgrade, providing a plethora of new features and improving performance:
On the other hand, there were a couple of pitfalls along the way. So Happy Upgrading and hopefully this post will save some headache for others.
