This project is archived and is in readonly mode.

after_update callback called when cascade destroying an association

#5680

Rails 3 installed with:
gem "rails", :git => "git://github.com/rails/rails.git", :branch => "3-0-stable"

class User < ActiveRecord::Base
  ...
  has_one :subscription, :dependent => :destroy, :inverse_of => :user

class Subscription < ActiveRecord::Base
  belongs_to :user
  has_many :transactions, :class_name => 'SubscriptionTransaction', :foreign_key => 'subscription_id', :dependent => :nullify

  after_update :async_adjust_user_library

Calling User#destroy

  ...
  Subscription Load (0.4ms)  SELECT subscriptions.* FROM subscriptions WHERE (subscriptions.user_id = 8168) LIMIT 1
  SQL (3.7ms)  UPDATE subscription_transactions SET subscription_id = NULL WHERE ((subscription_id = 8081))
[log] calling async_adjust_user_library

To my knowledge this should not happen. Sadly I don't have time right now to delve deeper in AR to write test/patch but if is there anything I can do let me know.

Reported by Claudio Poli · September 22nd, 2010 @ 07:54 AM

Activity

Neeraj Singh
- Importance changed from to Low
To my knowledge this should not happen

What is this. Can you elaborate?

September 22nd, 2010 @ 02:34 PM
Claudio Poli
I simply assume that an after_update callback should not be triggered on a destroy action.

The Subscription object is being destroyed due to the :dependent option, but not updated.

Yehuda said in IRC that this may be intended, though.

September 22nd, 2010 @ 02:38 PM
Neeraj Singh
- Assigned user set to Yehuda Katz (wycats)
September 22nd, 2010 @ 02:40 PM
Geoff Garside
I've been trying to work around this and noticed that before_destroy isn't called before the association is flushed either, so I can't set an instance variable on my model for the after_update callback to check for to see if its actually being deleted and should therefore not perform its task.

It would be nice if ActiveRecord::Base#destroyed? actually returned true before the associations were flushed, this would help in having after_update return early.

I've also tried looking at after_commit but that doesn't seem to fit my requirements as its not possible to discern if a model has been recently created or not. I should be able to hack something together, but it feels like AR::Base#destroyed? should return true once #destroy has been called, I'd love to hear thoughts on this. Additionally I find it a bit surprising that before_destroy isn't called before the association is flushed, but this could be an ordering issue perhaps.

It is probably worth noting all of my callbacks are in an Observer rather than the model, but I wouldn't have thought that would make a substantial difference with the possible exception of ordering callbacks.

November 3rd, 2010 @ 05:42 PM
Santiago Pastorino
- State changed from new to open
This issue has been automatically marked as stale because it has not been commented on for at least three months.

The resources of the Rails core team are limited, and so we are asking for your help. If you can still reproduce this error on the 3-0-stable branch or on master, please reply with all of the information you have about it and add "[state:open]" to your comment. This will reopen the ticket for review. Likewise, if you feel that this is a very important feature for Rails to include, please reply with your explanation so we can consider it.

Thank you for all your contributions, and we hope you will understand this step to focus our efforts where they are most helpful.

February 5th, 2011 @ 08:56 PM
Santiago Pastorino
- State changed from open to stale
February 5th, 2011 @ 08:56 PM
Geoffrey Hichborn
I have confirmed that this does indeed occur in the 3-0-6 branch. Running the tests in my rails 3.0.6 branch of my delete_paranoid gem will reveal this:

https://github.com/phene/delete_paranoid/tree/rails-3-0-6

April 4th, 2011 @ 08:29 PM
Geoffrey Hichborn
Actually, I just found an issue in my test and confirmed that this works properly in Rails.

https://github.com/phene/rails/tree/update-callbacks-triggered-on-d...

April 4th, 2011 @ 11:31 PM