views:

124

answers:

1

I have a sequence of ActiveRecord objects that I want to cascade destroy but some of the objects are not being removed.

Essentially I have as follows:-

class Project < ActiveRecord::Base

  has_many :tasks, :dependent => :destroy
  has_many :schedules, :dependent => :destroy
  has_many :project_schedules, :through => :schedules, :class_name => "Project", :dependent => :destroy

end

class Schedule < ActiveRecord::Base

  belongs_to :project_schedule, :class_name => "Project"
  belongs_to :project

end

class Task < ActiveRecord::Base

  belongs_to :project

end

where Project is a definition of a project, Task a definition of a task on that project and Schedule a has_many :through that links an original project to another project, which is a schedule of the original project.

When I create a schedule, I am deep-cloning the original project (i.e. the schedule is a clone of the original project and each of the tasks on the schedule are clones of the tasks on the original schedule).

When I do a schedule.destroy I would expect the schedule project and all it's associated tasks to be deleted. However, only the schedule project is deleted, the schedule tasks remain.

This isn't a caching issue as the records are still in the database. Also, there are definitely separate tasks being created in the database with schedule id as the project id and aunique id of their own.

Do callbacks still fire on cloned objects? Have I missed a trick here?

+1  A: 

From the look of your class descriptions, I would not expect a cascading delete when you destroy a Schedule object. If you delete a Project object, then Rails should go through child Tasks and Schedules (not really sure what Project Schedule is here) and delete the records because of the :dependent => :destroy option. Tasks and Schedules are children of Project and would not cause a parent to be deleted.

If you want to remove the parent Project when a Schedule is deleted I would probably look at writing an after_delete callback.

Michael Sepcot
Thanks, Michael. You're right, I was getting this the wrong way round. I'll look at using the after_delete callback. Many thanks.
Urf