This project is archived and is in readonly mode.

#5680 ✓stale
Claudio Poli

after_update callback called when cascade destroying an association

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

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.

Comments and changes to this ticket

  • Neeraj Singh

    Neeraj Singh September 22nd, 2010 @ 02:34 PM

    • Importance changed from “” to “Low”

    To my knowledge this should not happen

    What is this. Can you elaborate?

  • Claudio Poli

    Claudio Poli September 22nd, 2010 @ 02:38 PM

    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.

  • Neeraj Singh

    Neeraj Singh September 22nd, 2010 @ 02:40 PM

    • Assigned user set to “Yehuda Katz (wycats)”
  • Geoff Garside

    Geoff Garside November 3rd, 2010 @ 05:42 PM

    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.

  • Santiago Pastorino

    Santiago Pastorino February 5th, 2011 @ 08:56 PM

    • 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.

  • Santiago Pastorino

    Santiago Pastorino February 5th, 2011 @ 08:56 PM

    • State changed from “open” to “stale”
  • Geoffrey Hichborn

    Geoffrey Hichborn April 4th, 2011 @ 08:29 PM

    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

  • Geoffrey Hichborn

    Geoffrey Hichborn April 4th, 2011 @ 11:31 PM

    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...

Create your profile

Help contribute to this project by taking a few moments to create your personal profile. Create your profile »

<h2 style="font-size: 14px">Tickets have moved to Github</h2>

The new ticket tracker is available at <a href="https://github.com/rails/rails/issues">https://github.com/rails/rails/issues</a>

People watching this ticket

Pages