aboutsummaryrefslogtreecommitdiffstats
path: root/Rakefile
diff options
context:
space:
mode:
authorAgis- <corestudiosinc@gmail.com>2015-08-24 11:27:06 +0300
committerAgis- <corestudiosinc@gmail.com>2015-08-24 11:49:43 +0300
commit19b168e611fb8fb547981c4535130c29856efd3a (patch)
tree14ad6450b7da0940102d7a384b66fb55e4404935 /Rakefile
parentef8d09d932e36b0614905ea5bc3fb6af318b6ce2 (diff)
downloadrails-19b168e611fb8fb547981c4535130c29856efd3a.tar.gz
rails-19b168e611fb8fb547981c4535130c29856efd3a.tar.bz2
rails-19b168e611fb8fb547981c4535130c29856efd3a.zip
Only nullify persisted has_one target associations
Since after 87d1aba3c `dependent: :destroy` callbacks on has_one assocations run *after* destroy, it is possible that a nullification is attempted on an already destroyed target: class Car < ActiveRecord::Base has_one :engine, dependent: :nullify end class Engine < ActiveRecord::Base belongs_to :car, dependent: :destroy end > car = Car.create! > engine = Engine.create!(car: car) > engine.destroy! # => ActiveRecord::ActiveRecordError: cannot update a > destroyed record In the above case, `engine.destroy!` deletes `engine` and *then* triggers the deletion of `car`, which in turn triggers a nullification of `engine.car_id`. However, `engine` is already destroyed at that point. Fixes #21223.
Diffstat (limited to 'Rakefile')
0 files changed, 0 insertions, 0 deletions