Rails :Dependent =≫ :Destroy VS :Dependent =≫ :Delete_All

Rails :dependent = :destroy VS :dependent = :delete_all

The difference is with the callback.

The :delete_all is made directly in your application and deletes by SQL :

DELETE * FROM users where compagny_id = XXXX

With the :destroy, there is an instantiation of all of your children. So, if you can't destroy it or if each has their own :dependent, its callbacks can be called.

Difference between dependent destroy vs dependent delete on Rails Active Record

Yes, both will delete the database records but doing it in a different way.

You can check the answer for this question here:

Rails :dependent => :destroy VS :dependent => :delete_all

Basically dependent: :delete will execute the delete for the dependent records directly on the database without executing any activerecod validations or callbacks.

While dependent: :destroy will instantiate all the dependent records and execute a :destroy for each object (executing validations and callbacks).

Rails: Dependent delete_all not working

delete_all does not trigger call_backs.

If you have Game.destroy_all it will do what you want.

You can use :dependent => :destroy or :dependent => :delete_all in the association declaration. The former will run callbacks in the association and the later one does not.

dependent is set to destroy, nullifies instead

The relation was re-defined in a concern.

module Likeable
  extend ActiveSupport::Concern

  included do
    has_many :likes

    ...
  end
end

:dependent = :delete_all not working

You need to use :dependent => :delete or :dependent => :destroy

From the guide:

If you set the :dependent option to :destroy, then deleting this
object will call the destroy method on the associated object to delete
that object. If you set the :dependent option to :delete, then
deleting this object will delete the associated object without calling
its destroy method.

http://guides.rubyonrails.org/association_basics.html

Rails: delete cascade vs dependent destroy

It really depends on the behavior you want. In case 1, destroy will be called on each associated order, and therefor so will the ActiveRecord callbacks. In case 2, these callbacks are not triggered, but it will be way faster and guarantees referential integrity.

In an application's infancy, I'd recommend going with :dependent => :destroy because it lets you develop in a way that is independent of the database. Once you start to scale, you should start doing it in the database for performance/integrity reasons.

Where to use dependent: :destroy

(1) In User model, has_many :receipts, dependent: :destroy

If user is destroyed then its associated receipts will be destroyed as well.

(2) In Receipt model, belongs_to :user, dependent: :destroy

If receipt is destroyed then its parent user will be destroyed, not other associated receipts would not be destroyed but would be orphaned. According to docs

This dependent: option should not be specified when belongs_to is used in
conjunction with a has_many relationship on another class because of
the potential to leave orphaned records behind.

Rails: How to use dependent: :destroy in rails?

Add cascading delete to your EmpGroup model:

class EmpGroup < ActiveRecord::Base
   has_many :emp_group_members, dependent: :delete_all
end

Or

Are you calling delete method? you should call destroy instead.
Use .destroy

Rails 4.2 dependent: :destroy problems with CollectionProxy

Sometimes, when your stuck going around circles, you just have to ask a question. When you don't get an answer, you've had time to rethink the problem. I guess I didn't try all the options.

I think the problem is my not understanding default strategy of nullify. According to my goals, you can't have a value without a property and vice versa. Trying to destroy using a through association would raise the pg error. The simple solution that I apparently didn't try was to dependent destroy properties in the Subject model and dependent destroy value in the Property model. The warning in the guide not to use dependent destroy on a belongs_to association may have started my circle trip. I'm still not sure I understand the warning. My guess is that when subject.properties is destroyed, the subject_id is set to null before the property.value destroy call is made, avoiding the pg error. My cleaned up models:

    class Subject < ActiveRecord::Base
        has_many :properties, dependent: :destroy
        has_many :values, :through => :properties
        has_many :tags, :through => :properties

    class Property < ActiveRecord::Base
      belongs_to :subject
      belongs_to :tag
      belongs_to :value, dependent: :destroy

    class Value < ActiveRecord::Base
        has_one :property
        has_one :subject, :through => :property
        has_one :tag, :through => :property

---

Related Topics