From 8d98c83bbceb905cd65c487cfa714d2fca92501c Mon Sep 17 00:00:00 2001 From: Jason Stirk Date: Thu, 3 Jan 2013 22:26:53 +1100 Subject: Fix undefined method `to_i' introduced since 3.2.8 This commit fixes a bug introduced in 96a13fc7 which breaks behaviour of integer fields. In 3.2.8, setting the value of an integer field to a non-integer (eg. Array, Hash, etc.) would default to 1 (true) : # 3.2.8 p = Post.new p.category_id = [ 1, 2 ] p.category_id # => 1 p.category_id = { 3 => 4 } p.category_id # => 1 In 3.2.9 and above, this will raise a NoMethodError : # 3.2.9 p = Post.new p.category_id = [ 1, 2 ] NoMethodError: undefined method `to_i' for [1, 2]:Array Whilst at first blush this appear to be sensible, it combines in bad ways with scoping. For example, it is common to use scopes to control access to data : @collection = Posts.where(:category_id => [ 1, 2 ]) @new_post = @collection.new In 3.2.8, this would work as expected, creating a new Post object (albeit with @new_post.category_id = 1). However, in 3.2.9 this will cause the NoMethodError to be raised as above. It is difficult to avoid triggering this error without descoping before calling .new, breaking any apps running on 3.2.8 that rely on this behaviour. This patch deviates from 3.2.8 in that it does not retain the somewhat spurious behaviour of setting the attribute to 1. Instead, it explicitly sets these invalid values to nil : p = Post.new p.category_id = [ 1, 2 ] p.category_id # => nil This also fixes the situation where a scope using an array will "pollute" any newly instantiated records. @new_post = @collection.new @new_post.category_id # => nil Finally, 3.2.8 exhibited a behaviour where setting an object to an integer field caused it to be coerced to "1". This has not been retained, as it is spurious and surprising in the same way that setting Arrays and Heshes was : c = Category.find(6) p = Post.new # 3.2.8 p.category_id = c p.category_id # => 1 # This patch p.category_id = c p.category_id # => nil This commit includes explicit test cases that expose the original issue with calling new on a scope that uses an Array. As this is a common situation, an explicit test case is the best way to prevent regressions in the future. It also updates and separates existing tests to be explicit about the situation that is being tested (eg. AR objects vs. other objects vs. non-integers) --- .../test/cases/associations/belongs_to_associations_test.rb | 12 ++++++++++++ 1 file changed, 12 insertions(+) (limited to 'activerecord/test/cases/associations/belongs_to_associations_test.rb') diff --git a/activerecord/test/cases/associations/belongs_to_associations_test.rb b/activerecord/test/cases/associations/belongs_to_associations_test.rb index 97a3d57fe0..3a6da0e59f 100644 --- a/activerecord/test/cases/associations/belongs_to_associations_test.rb +++ b/activerecord/test/cases/associations/belongs_to_associations_test.rb @@ -63,6 +63,13 @@ class BelongsToAssociationsTest < ActiveRecord::TestCase assert_equal apple.id, citibank.firm_id end + def test_id_assignment + apple = Firm.create("name" => "Apple") + citibank = Account.create("credit_limit" => 10) + citibank.firm_id = apple + assert_nil citibank.firm_id + end + def test_natural_assignment_with_primary_key apple = Firm.create("name" => "Apple") citibank = Client.create("name" => "Primary key client") @@ -567,6 +574,11 @@ class BelongsToAssociationsTest < ActiveRecord::TestCase assert_equal new_firm.name, "Apple" end + def test_attributes_are_set_without_error_when_initialized_from_belongs_to_association_with_array_in_where_clause + new_account = Account.where(:credit_limit => [ 50, 60 ]).new + assert_nil new_account.credit_limit + end + def test_reassigning_the_parent_id_updates_the_object client = companies(:second_client) -- cgit v1.2.3