I've noticed that if I use associations with has_many_and_belongs_to and i call a destroy method on an object of the association, the record in the join table is automatically deleted. If I use has_many :though, for example:
Category has_many :categorizations has_many :products, :through => :categorizations
I have to put explicity
has_many :categorization, :dependent => :destroy
otherwise the association isn't deleted. Why?
Msan Msan wrote in post #1061478:
I've noticed that if I use associations with has_many_and_belongs_to and i call a destroy method on an object of the association, the record in the join table is automatically deleted. If I use has_many :though, for example:
Category has_many :categorizations has_many :products, :through => :categorizations
I have to put explicity
has_many :categorization, :dependent => :destroy
otherwise the association isn't deleted. Why?
A HABTM B (to me) infers that the join table AB serves no purpose other than to link As and Bs. Without a specific A, the AB record has no meaning. So the HABTM specification lets Rails make the assumption that when A is deleted, the AB related to that A can be deleted as well.
A has_many B A has_many C, through B implies (also to me) that joining through the intermediary table B is an artifact of the relationships between As, Bs, and Cs, and the entity modeled in B has value independent of its relationship between A and C. Like
Project has_many :scenarios has_many :unittests, :through => :scenarios
When a Project is deleted, I don't want all those Scenarios deleted...
Unittest has_many :testings, :dependent => :destroy has_many :testresults, :through => :testings
When a unittest is deleted, I delete all the testings (and testresults) since test results or testing instances aren't much use without the requirements (the unittest).