Dirty tracking on serialized columns is broken

Hm. Trying once more since Lighthouse formatting eluded me.

class Monkey < ActiveRecord::Base

serialize :legs, Array

end

and

Loading development environment (Rails 2.1.0)

>> m = Monkey.create

=> #

>> m.changed?

=> false

>> m.legs = [1,2,3,4]

=> [1, 2, 3, 4]

>> m.changed?

=> true

Eh, I give up. Trying Textile but it's not working. You get the idea.

I couldn't reproduce this either. I did, however, find that dirty tracking doesn't work with in-place manipulation of said serialized column:

>> m.legs
=> [1, 2, 3]
>> m.changed?
=> false
>> m.legs << 4
=> [1, 2, 3, 4]
>> m.changed?
=> false

IMHO, AR should let the object itself figure out whether it's been changed or not. If anything, AR could provide a way for either: (a) the serialized object to notify AR that the attribute has been changed, or (b) AR to optionally query the serialized object when its own #changed? is called.

I can't reproduce this error in rails 2.1, however, dirty checking is broken is this case:

>> m.reload

>> m.legs = m.legs << 4

>> m.changed?

=> false

Why was this ticket changed to 'invalid'? This is still broken as far as I can tell (yes, AR knows if the field went from nil to an array, but it still can't tell if an existing serialized array was modified).

If you have a serialized field named "array_field", then "array_field_was" method doesn't return what array_field was, and "array_field_changed?" doesn't tell you if array_field was changed. To me that looks like clearly broken behavior (and I don't think the docs anywhere specify that one ought to expect different behavior for serialized fields)..

This still happens on Rails 2.3.5
if serialized changes of type (nil to Array, Array to Hash..) changed? method returns true, but not if serialized changes conserving its type (adding an element to array..)

This is no longe an issue with rail3.

This is what I found on rails edge.

ActiveRecord::Schema.define(:version => 20100516025941) do

  create_table "users", :force => true do |t|
    t.string   "name"
    t.text     "bio"
  end

end
class User < ActiveRecord::Base
  serialize :bio
end
#rails -v : Rails 3.0.0.beta3
#ruby -v : ruby 1.8.7 (2010-01-10 patchlevel 249) [i686-darwin10.3.0]

> u = User.create
> u.changed?
 => false 
> u.bio = 'w'
 => "w" 
> u.changed?
 => true 
> u.changes
 => {"bio"=>[nil, "w"]}

In rails 3 this is what I am getting

class User < ActiveRecord::Base
  serialize :bio

  def self.lab
    u = User.create
    assert !u.changed?
    u.bio = {:social => :github}
    assert u.changed?

    u.reload
    u.bio = {}
    u.bio[:social] = :github
    assert u.changed?
  end
end

All assertions are passing.

@neeraj, if u.bio is nil then assigning a hash to it will show a change because it is no longer nil.

Try it with a user that has bio already set and saved, then assign a key:

u.bio = {}
u.save
u.bio[:social] = :github
assert u.changed?

In case someone wants to see the complete solution. Here it is with the usage of attribute_will_change!

class User < ActiveRecord::Base
  serialize :bio

  def self.lab
    u = User.create(:bio => {:eye_color => "black"})
    assert !u.changed?
    u.bio = {:social => :github}
    assert u.changed?

    u.reload
    u.send(:attribute_will_change!, :bio)
    u.bio[:eye_color] = :green
    assert u.changed?
  end
end

José, you said this is mentioned in the documentation. Where?

And here's a more idiomatic example of how to do the right thing with attribute_will_change!:

    class User < ActiveRecord::Base
      serialize :bio
    
      def self.lab
        u = User.create(:bio => {:eye_color => "black"})
        assert !u.changed?
        u.bio = {:social => :github}
        assert u.changed?

        u.reload
        u.bio_will_change!
        u.bio[:eye_color] = :green
        assert u.changed?
      end
    end