What are the default values for Rails 3 for :dependent on has_many and belongs_to
Asked Answered
C

3

13

In rails 3, i know that i can force deletion of dependent objects on belongs_to and has_many relations using the :dependent => :delete option. However i was wondering,

what is the default behavior if i do not specify :dependent => ...

Cheers, Hajo

Crumhorn answered 26/6, 2011 at 17:28 Comment(1)
if you don't specify this, you'll end up with abandoned children crying for their parents. That's not a big deal but it keeps your db filled with (useless) dataCadaverine
P
22

The documentation says, "When no option is given, the behavior is to do nothing with the associated records when destroying a record." That is, deleting or destroying an object will not delete or destroy the objects that it belongs to or has many of.

Poser answered 26/6, 2011 at 17:39 Comment(1)
Thanks for pointing that out :) I'd expect rails to try to use DB queries to load dependent objects, if their ID fields are not properly nullified. This means, wasting CPU and DB time to search for non-existant records. So i wonder why rails isn't doing anything about it by default ...Crumhorn
G
5

has_many uses the :nullify strategy, which will set the foreign to null. For has_many :through it will use delete_all.

For has_many, destroy will always call the destroy method of the record(s) being removed so that callbacks are run. However delete will either do the deletion according to the strategy specified by the :dependent option, or if no :dependent option is given, then it will follow the default strategy. The default strategy is :nullify (set the foreign keys to nil), except for has_many :through, where the default strategy is delete_all (delete the join records, without running their callbacks).

-- ActiveRecord::Associations::ClassMethods

Not sure exactly what belongs_to does, and wasn't able to find anything in the docs. I'll try to do some digging soon and update the answer.

Ganister answered 2/5, 2013 at 2:37 Comment(3)
Are you sure this is still the case? I just experienced that the default behavior is NOT to nullify the foreign keys. I had to set dependent: :nullify explicitly to get it to nullify. I'm using ruby 2.0.0 and Rails 4.0.0.Oversleep
Do you know what the default is for has_one?Telegony
This is not true any longer: The default strategy is to do nothing (leave the foreign keys with the parent ids set), except for has_many :through, where the default strategy is delete_all (delete the join records, without running their callbacks).Evy
T
4

In Rails 3, the default :dependent value is :nullify which sets foreign keys to nil.

The default strategy is :nullify for regular has_many. Also, this only works at all if the source reflection is a belongs_to.

Source: http://guides.rubyonrails.org/3_1_release_notes.html#active-record

This is still the case in Rails 4.

However delete and delete_all will either do the deletion according to the strategy specified by the :dependent option, or if no :dependent option is given, then it will follow the default strategy. The default strategy is :nullify (set the foreign keys to nil), except for has_many :through, where the default strategy is delete_all (delete the join records, without running their callbacks).

Source: http://api.rubyonrails.org/classes/ActiveRecord/Associations/ClassMethods.html#module-ActiveRecord::Associations::ClassMethods-label-Delete+or+destroy%3F

Also see the source code docs: https://github.com/rails/rails/blob/b5a8fd7bb4a6fa4b67d4eabae4cea2cb1834d8d9/activerecord/lib/active_record/associations/collection_proxy.rb#L369

Tarantass answered 12/12, 2014 at 15:37 Comment(1)
Unfortunately this is not correct. The quoted docs refer to calling delete/delete_all on a has_many association (like blog.posts.delete_all). Calling blog.destroy on a model - not on a relation - will not do anything at all to associated models unless the has_many relation specifies a dependent behavior. (The default is to leave dangling references)Fingered

© 2022 - 2024 — McMap. All rights reserved.