Ruby on Rails Triggers Update on Serialized Attribute Every Time - ruby-on-rails

I have a simple user model with a name and settings. After every save of user AREL is performing an update to the settings column. For example:
user = User.find_by_name('kevin')
user.save
(0.3ms) UPDATE "users" SET "updated_at" = '2011-10-20 19:58:06.363541', "settings" = '--- {}' WHERE "users"."id" = 1
None of the other fields are updated when calling save. Is this expected behavior? Why is it performing the update? Can it be turned off to not change if the serialized contents haven't changed? I've uploaded the sample project used to create a minimum case:
http://cl.ly/0p0j3Z3Y0L1x1I1p3Z0g

This is expected behavior. It is very difficult to detect changes within a serialized attribute, so they are updated on every save.
Consider the following (ruby 1.8.7) irb session:
ruby-1.8.7-p352 :001 > x = "--- \n:b: 2\n:a: 1\n"
=> "--- \n:b: 2\n:a: 1\n"
ruby-1.8.7-p352 :002 > y = "--- \n:a: 1\n:b: 2\n"
=> "--- \n:a: 1\n:b: 2\n"
ruby-1.8.7-p352 :003 > x == y
=> false
ruby-1.8.7-p352 :004 > YAML.load(x) == YAML.load(y)
=> true

Related

ActiveRecord class (enum) behaving incorrectly with patch in config/initializers

I'm using ruby 2.2.3 and rails 4.2.4.
Background: I need the ability to re-use values across enums within the same model so I have patched in the latest version of Active Record's enum.rb as config/initializers/enum_patch.rb since they are adding prefix/suffix support in Rails 5 which will enable this functionality.
Issue: After patching in the code, Enum is no longer working correctly. See below:
class GatheringSession < ActiveRecord::Base
GatheringStates = %i(ready running finished errored)
enum :gathering_state => GatheringStates
...
end
Console (no patch). Correct behaviour:
2.2.3 :001 > gs2 = GatheringSession.last
=> #<GatheringSession id: 120, gathering_state: 2 ... >
2.2.3 :002 > gs2.gathering_state
=> "finished"
2.2.3 :003 > gs2.ready?
=> false
2.2.3 :004 > gs2.finished?
=> true
2.2.3 :005 > gs2.ready!
=> true
2.2.3 :007 > gs2.ready?
=> true
2.2.3 :008 > gs2.finished?
=> false
2.2.3 :009 > gs2.finished!
=> true
2.2.3 :010 > gs2.finished?
=> true
Console (patch):
2.2.3 :001 > gs2 = GatheringSession.last
=> #<GatheringSession id: 120, gathering_state: 2 ... >
2.2.3 :002 > gs2.gathering_state
=> 2
2.2.3 :003 > gs2.ready?
=> false
2.2.3 :004 > gs2.finished?
=> false
2.2.3 :005 > gs2.ready!
(0.2ms) BEGIN
SQL (0.8ms) UPDATE `gathering_sessions` SET `gathering_state` = 'ready', `updated_at` = '2015-10-31 00:28:36' WHERE `gathering_sessions`.`id` = 120
Mysql2::Error: Incorrect integer value: 'ready' for column 'gathering_state' at row 1: UPDATE `gathering_sessions` SET `gathering_state` = 'ready', `updated_at` = '2015-10-31 00:28:36' WHERE `gathering_sessions`.`id` = 120
(0.1ms) ROLLBACK
ActiveRecord::StatementInvalid: Mysql2::Error: Incorrect integer value: 'ready' for column 'gathering_state' at row 1: UPDATE `gathering_sessions` SET `gathering_state` = 'ready', `updated_at` = '2015-10-31 00:28:36' WHERE `gathering_sessions`.`id` = 120
...
from /Users/william/.rvm/gems/ruby-2.2.3/gems/activerecord-4.2.4/lib/active_record/persistence.rb:263:in `update!'
from /Users/william/code/repo/config/initializers/enum_patch.rb:193:in `block (4 levels) in enum'
After doing a little bit of testing, I've realized the problem is not the new code that I've patched in, but the fact that I'm patching in code period. Even when using the same code that is shipped with Rails 4.2.4 (here) I get the same (incorrect) behaviour.
Does anyone have an idea why this is happening and how I can fix it?

Ruby on Rails Dirty method _was not working with serialized field

I have a model that looks like this:
class WorkRequest < ActiveRecord::Base
attr_accessible :upload, :assigned_to_staff
serialize :assigned_to_staff, Array
before_save :set_old_staff
def set_old_staff
#old_staff = self.assigned_to_staff_was
end
def staff_changed?
!self.assigned_to_staff.empty? && self.assigned_to_staff != #old_staff
end
end
I'm trying to make use of self.assigned_to_was to track when a staff assignment change takes place. I'm noticing that the serialized field behaves differently than a regular field. Console output below shows differing behavior in :upload (text string field) and the serialized :assigned_to_staff:
1.9.2-p320 :002 > wr.upload
=> nil
1.9.2-p320 :003 > wr.upload_was
=> nil
1.9.2-p320 :004 > wr.upload = "Yes"
=> "Yes"
1.9.2-p320 :005 > wr.upload_was
=> nil
compared to:
1.9.2-p320 :006 > wr.assigned_to_staff
=> []
1.9.2-p320 :007 > wr.assigned_to_staff_was
=> []
1.9.2-p320 :008 > wr.assigned_to_staff << User.last.name
User Load (0.2ms) SELECT `users`.* FROM `users` ORDER BY `users`.`id` DESC LIMIT 1
=> ["last5, first5"]
1.9.2-p320 :009 > wr.assigned_to_staff_was
=> ["last5, first5"]
Can anyone explain this discrepancy and or suggest a workaround?
It appears that serialization doesn't fully implement all methods of the host class. Overrides are provided for getters and setters, but not concatenation.

ActiveRecord object marked as dirty when old value and new value are both numeric zero

I have a model called Day that represents a day in a timesheet. I've noticed that whenever I call #day.save it's writing to the database, even though none of the object's properties have had their values changed.
#day = Day.last
=> #<Day lunch_minutes: 0, updated_at: "2012-08-19 12:09:40", work_hours: 5.5>
A day has its length in hours, and the length of its lunch break in minutes, stored. I've cropped out some properties that aren't relevant.
#day.lunch_minutes
=> 0
#day.lunch_minutes = 0
=> 0
#day.changes
=> {"lunch_minutes"=>[0, 0]}
#day.lunch_minutes_changed?
=> true
That should be false. Compare to a value that isn't zero:
#day.work_hours = 5.5
=> 5.5
#day.work_hours_changed?
=> false
So if I call save, this gets called. Ideally there would be no unnecessary database interaction here.
#day.save
(0.5ms) UPDATE "days" SET "lunch_minutes" = 0, "updated_at" = '2012-08-19 12:22:59.586860' WHERE "days"."id" = 48
I'm not sure if this is a Rails bug or if I'm doing some incorrectly somewhere. It looks like it could be an issue in "changes_from_zero_to_string?" - I think adding a && value != 0 to that method would fix it - but I want to know if anyone else has seen this/a fix for this before?
What version of rails are you using? I just had a go in my app (3.1.5/1.8.7) and it doesn't behave this way.. I just used a random integer property on one of my models to test with:
1.8.7 :006 > o = Order.first
=> <Order id:...>
1.8.7 :007 > o.order_items_count
=> 0
1.8.7 :008 > o.order_items_count = 0
=> 0
1.8.7 :009 > o.changes
=> {}
1.8.7 :010 > o.order_items_count = '0'
=> "0"
1.8.7 :011 > o.changes
=> {}
1.8.7 :012 > o.save
(0.1ms) BEGIN
(0.1ms) COMMIT
=> true
It appears to be a bug.
Interestingly, according to the code, if you do:
#day.lunch_minutes = '0'
It will probably think it has not changed!
Try that, and if indeed this change causes #day.lunch_minutes_changed? to be false, then make sure it is reported as an issue to https://github.com/rails/rails.

Why does rails change the type of the attribute _was value after it is set?

I have an attribute in my model that is stored as text but interpreted as a rational. I have this method to handle that:
def start
read_attribute(:start).to_r
end
When I set the start attribute to a new value, the start_was helper method returns a string, instead of a rational, but before I do so, it returns the correct value. Why?
Loading development environment (Rails 3.2.8)
1.9.3p194 :001 > d = Day.find(55)
Day Load (8.7ms) SELECT "days".* FROM "days" WHERE "days"."id" = ? LIMIT 1 [["id", 55]]
=> #<Day id: 55, date: "2012-03-30", start: "1/2", finish: "2/2", created_at: "2012-09-18 15:16:42", updated_at: "2012-09-19 08:20:41", day_year_id: 1>
1.9.3p194 :002 > d.start_was
=> (1/2)
1.9.3p194 :003 > d.start=0
=> 0
1.9.3p194 :004 > d.start_was
=> "1/2"
I think the reason is this method in ActiveModel (activemodel-3.2.8\lib\active_model\dirty.rb)
# Handle <tt>*_was</tt> for +method_missing+.
def attribute_was(attr)
attribute_changed?(attr) ? changed_attributes[attr] : __send__(attr)
end
As you see, if attribute was not actually changed it just calls its own getter, in your case hitting your start method which does the transformation. But if the attribute is actually changed, it reads its raw value from the changed_attributes storage.

rake / rails .save! not updating database

I am trying to save changes to my database trough a rake task.
In my rake task I do something like:
namespace :parts do
desc "Update Parts table, swap names in title"
task :swap => :environment do
Part.swap
end
end
In my Part class I do
def self.swap
Part.all.each do |part|
if (part.title =~ REGEX) == 0
part.title.gsub! REGEX, '\2 \1'
puts part.title
part.save!
end
end
end
However, this does not save the part. The save! does return true. the puts part.title does return the value I want.
If I call
Part.update(part.id, title: part.title)
The database updates properly. Why is this? Am I doing something wrong in my loop?
I am working with Rails 3.1.3, Rake 0.9.2.2 and MySQL2 0.3.7
It's because the way ActiveRecord detects that attributes are changed is through the setter. Therefore, if you use gsub! on an attribute, ActiveRecord doesn't know it needs to update the database.
You'll probably have to do this:
part.title = part.title.gsub REGEX, '\2 \1'
Update from comment
Also, if you try to assign title to another variable and then gsub! it won't work either because it's the same object (code from my project, variable names different).
ruby-1.9.3-p0 :020 > t = p.name
=> "test"
ruby-1.9.3-p0 :023 > t.object_id
=> 70197586207500
ruby-1.9.3-p0 :024 > p.name.object_id
=> 70197586207500
ruby-1.9.3-p0 :025 > t.gsub! /test/, 'not a test'
=> "not a test"
ruby-1.9.3-p0 :037 > p.name = t
=> "not a test"
ruby-1.9.3-p0 :026 > p.save
(37.9ms) BEGIN
** NO CHANGES HERE **
(23.9ms) COMMIT
=> true
You have to .dup the string before modifying it.
ruby-1.9.3-p0 :043 > t = p.name.dup
=> "test"
ruby-1.9.3-p0 :044 > t.gsub! /test/, 'not a test'
=> "not a test"
ruby-1.9.3-p0 :045 > p.name = t
=> "not a test"
ruby-1.9.3-p0 :046 > p.save
(21.5ms) BEGIN
(20.8ms) UPDATE "projects" SET "name" = 'not a test', "updated_at" = '2012-01-02 07:17:22.892032' WHERE "projects"."id" = 108
(21.5ms) COMMIT
=> true

Resources