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 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+unsubscribe@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/6afe728a-9585-4431-bc96-71f6f8ceaeeb%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Search Discussions

  • Eric Krause at Dec 17, 2015 at 5:23 pm
    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 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+unsubscribe@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/36dc4015-38a9-47de-bc37-99c4b3eca150%40googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Spike22 at Dec 17, 2015 at 9:38 pm
    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 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+unsubscribe@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.
    For more options, visit https://groups.google.com/d/optout.
  • Eric Krause at Dec 17, 2015 at 9:39 pm
    I just did that this morning.
    On Thursday, December 17, 2015, spike22 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+unsubscribe@googlegroups.com
    <javascript:_e(%7B%7D,'cvml','rubyonrails-talk%2bunsubscribe@googlegroups.com');>
    .
    To post to this group, send email to rubyonrails-talk@googlegroups.com
    <javascript:_e(%7B%7D,'cvml','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+unsubscribe@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/CAMtp6HebCtGxrnNExkU0S6v-cK2Q4%3D71%2B_y-g44Bos1GBRkYCw%40mail.gmail.com.
    For more options, visit https://groups.google.com/d/optout.
  • Spike22 at Dec 17, 2015 at 9:43 pm
    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
    <javascript:>> 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+unsubscribe@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+unsubscribe@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/9764458c-f0a0-4a16-aa14-3a03d1f2ee8a%40googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Spike22 at Dec 18, 2015 at 9:46 am
    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+unsubscribe@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+unsubscribe@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.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouprubyonrails-talk @
categoriesrubyonrails
postedDec 15, '15 at 12:44a
activeDec 18, '15 at 9:46a
posts6
users2
websiterubyonrails.org
irc#RubyOnRails

2 users in discussion

Spike22: 4 posts Eric Krause: 2 posts

People

Translate

site design / logo © 2021 Grokbase