Just reporting back, it works as expected on my end too. Thanks for the feedback. This solution feels more proper :)
Linking in the PR for the documentation change for others finding this thread in the future: https://github.com/rails/rails/pull/22644 Cheers, Brendon On Friday, December 18, 2015 at 10:43:07 AM UTC+13, spike22 wrote: > > Haha! very good :) > > On Friday, December 18, 2015 at 10:39:49 AM UTC+13, Eric Krause wrote: >> >> I just did that this morning. >> >> On Thursday, December 17, 2015, spike22 <bre...@spikeinsights.co.nz> >> wrote: >> >>> Hi Eric, that's really interesting! I'll give it a whirl and report back >>> :) I might do a documentation pull request to clarify this too. >>> >>> Have a great day! >>> >>> Brendon >>> >>> On Friday, December 18, 2015 at 6:23:50 AM UTC+13, Eric Krause wrote: >>>> >>>> I responded on stackoverflow, but I'll do here as well so that it is >>>> covered everywhere on the internet. >>>> >>>> In my case I was doing something similar to what you were doing and was >>>> running into the same issue with the join table being deleted instead of >>>> destroyed. >>>> >>>> I started looking through the code and I believe the documentation is >>>> just out of date. >>>> [has_many_through_association]( >>>> https://github.com/rails/rails/blob/master/activerecord/lib/active_record/associations/has_many_through_association.rb#L131 >>>> ) >>>> >>>> All you need to do is add the dependent: :destroy to the has_many >>>> :through relationship. >>>> >>>> class User >>>> has_many :partnerships, dependent: :destroy >>>> has_many :partners, through: :partnerships, dependent: :destroy >>>> end >>>> >>>> The pain I was dealing with was: >>>> >>>> user.partner_ids = [1,2,3] >>>> #creates the relationships >>>> user.partner_ids = [] >>>> #was deleting the records from partnerships without callbacks. >>>> >>>> The dependent: :destroy on the partners relationship fixed that. >>>> Callbacks are now being run and things are good again. >>>> >>>> Eric >>>> >>>> On Monday, December 14, 2015 at 5:43:57 PM UTC-7, spike22 wrote: >>>>> >>>>> I've asked this on on Stack Overflow but didn't receive much of a >>>>> response: >>>>> >>>>> The Rails 4 documentation says this regarding destroy callbacks on the >>>>> join model for a has_many :through relationship: >>>>> >>>>> collection=objects Replaces the collections content by deleting and >>>>> adding objects as appropriate. If the :through option is true callbacks >>>>> in >>>>> the join models are triggered except destroy callbacks, since deletion is >>>>> direct. >>>>> >>>>> Thankfully it's documented at least, but I want to know why on earth >>>>> this is the case? It makes more sense to trigger destroy callbacks (or >>>>> have >>>>> the option to) on a :through since these types of models can have destroy >>>>> callbacks and other associations. >>>>> >>>>> In my case I had a has_and_belongs_to_many relationship on the join >>>>> tables model off to another model. The records on that second join table >>>>> would never be deleted when the associated records on the first join >>>>> table >>>>> were deleted. I resorted to this which feels hacky, and I have to repeat >>>>> myself on each side of the :through relationship: >>>>> >>>>> class SchoolsTemplate < ActiveRecord::Base >>>>> >>>>> belongs_to :school >>>>> belongs_to :template >>>>> >>>>> has_and_belongs_to_many :groups >>>>> >>>>> end >>>>> >>>>> >>>>> class School < ActiveRecord::Base >>>>> >>>>> has_many :schools_templates, dependent: :destroy >>>>> has_many :templates, through: :schools_templates, before_remove: >>>>> :remove_groups_school_templates >>>>> >>>>> private >>>>> def remove_groups_school_templates(template) >>>>> schools_templates.where(template: template).first.groups.clear end >>>>> >>>>> end >>>>> >>>>> There's a validation to 'ensure' uniqueness on the join tables records >>>>> between the two foreign keys, so that's why I can call first in the >>>>> callback. >>>>> >>>> -- >>> You received this message because you are subscribed to a topic in the >>> Google Groups "Ruby on Rails: Talk" group. >>> To unsubscribe from this topic, visit >>> https://groups.google.com/d/topic/rubyonrails-talk/eGJRC4hDDuQ/unsubscribe >>> . >>> To unsubscribe from this group and all its topics, send an email to >>> rubyonrails-talk+unsubscr...@googlegroups.com. >>> To post to this group, send email to rubyonrails-talk@googlegroups.com. >>> To view this discussion on the web visit >>> https://groups.google.com/d/msgid/rubyonrails-talk/9eb239ab-b444-4b74-837d-503b589516a2%40googlegroups.com >>> >>> <https://groups.google.com/d/msgid/rubyonrails-talk/9eb239ab-b444-4b74-837d-503b589516a2%40googlegroups.com?utm_medium=email&utm_source=footer> >>> . >>> For more options, visit https://groups.google.com/d/optout. >>> >> >> >> -- >> >> Eric Krause >> > -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To unsubscribe from this group and stop receiving emails from it, send an email to rubyonrails-talk+unsubscr...@googlegroups.com. To post to this group, send email to rubyonrails-talk@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/rubyonrails-talk/1d287ee7-5455-46f8-a7ab-2fcfd5cfbcc2%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
