Question

I have a situation where I would like to update a dependency of a parent object after another object has been destroyed. Here is an example of the class hierarchy:

class Parent < ActiveRecord::Base
  has_one  :info, :dependent => :destroy
  has_many :conditions, :dependent => :destroy
  ....
end

class Info < ActiveRecord::Base
  belongs_to :parent

  def recalculate
    # Do stuff
  end
  ....
end

class Condition < ActiveRecord::Base
  belongs_to :parent
  has_one :condition_detail

  after_destroy :update_info

  def update_info
    parent.info.recalculate
    parent.info.save(:validate => false)
  end
  ....
end

The problem is that when the parent is destroyed, it destroys the condition, which then sets off the after_destroy callback and saves the info object after it was already destroyed. So after the parent is destroyed info still exists. If I don’t bypass validations, the save will silently fail, which I don’t want. And using save! raises an exception.

The callback on Condition has to be an after_destroy because otherwise the recalculate method on Info won’t have the correct representation of the state of the relationships to compute what it needs to.

I feel like I need a way to bypass callbacks when the parent is destroyed, but I don’t think that’s possible. I can’t use dependent => delete_all because that will not destroy the children of Condition. I tried seeing if there was a way I could tell if the parent had destroy called on it and use that info to bypass the save in the after_destroy, but that didn’t seem to work either.

Any help would be greatly appreciated, thanks!

Answer 1

I see there being 2 options:

1. Don’t use a after_destroy callback on Condition, but rather expect the info to be recalculated by whoever is destroying Condition. This is the cleanest, because you’re decoupling two separate intents: object destruction and calculation. You can see where this would be more helpful if, say, someday you want to destroy 2 conditions at once and only recalculate after both are destroyed. You cannot do this with a callback. It also aligns more closely with the Law of Demeter – the caller of Condition.destroy calling info.recalculate is better than Condition calling parent.info.recalculate.

   If you really want to package this behavior in Condition, create a #destroy_and_recalculate function that is called instead of just #destroy with a sort-of-hidden callback. It’s more obvious to callers that you are going to kick off a recalculation.

2. Remove :dependent=>destroy on the parent’s :condition association, and replace it with your own before_destroy callback on Parent that will cause condition to be destroyed without callbacks.

   In Condition, I would create this method, say, #destroy_without_callbacks, and in it destroy Condition’s children, then cause condition to delete itself.

The functionality of :dependent=>destroy is great, but with cycles like this, I think the clearest method by far is to make it very explicit what you’re doing by taking away some of the magic and managing the object and process lifecycle more explicitly.