Forum: Ruby on Rails Why isn't there a :dependent => false option?

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
34e92ab37b405e5abed7e7c8bf7ba5b7?d=identicon&s=25 Ed Lebert (Guest)
on 2008-12-16 16:45
(Received via mailing list)
I have an "audit" table that records when changes are made to another
table.  If a record is destroyed, I don't want all the change audits
for that record destroyed or nullified along with it.
Ed437e52d8d6720308720e7e678f3e6d?d=identicon&s=25 Patrick Doyle (Guest)
on 2008-12-16 17:38
(Received via mailing list)
On Tue, Dec 16, 2008 at 10:29 AM, Ed Lebert <edlebert@gmail.com> wrote:

>
> I have an "audit" table that records when changes are made to another
> table.  If a record is destroyed, I don't want all the change audits
> for that record destroyed or nullified along with it.
>
> How about :dependent => :nullify, or perhaps not attaching :dependent at
all to your model which (I am presuming) :has_many of the other model?

--wpd
6ef8cb7cd7cd58077f0b57e4fa49a969?d=identicon&s=25 Brian Hogan (Guest)
on 2008-12-16 17:43
(Received via mailing list)
@Ed:

Just leave the :dependent option off completely and nothing happens to
the other records.  That's the default behavior.
280b78a61a968391b7e07e912be102a8?d=identicon&s=25 Robert Walker (robert4723)
on 2008-12-16 18:32
I think a better question is, "Why isn't there a :dependent => :deny
option?"

It's very common to have a relational dependency where you want to deny
the deletion of an object that has related objects. It would be really
nice if this referential integrity rule was part of Rails core rather
than having to write it yourself or use a plugin.

It doesn't seem to me that it would be too difficult to add, if the
count of the related objects is greater than zero deny the deletion.

Example:

Employee
  belongs_to :department

Department
  has_many :employees, :dependent => :deny

Deny deletion of a department if the department contains one or more
employees.
171ea139761951336b844e708d1547ab?d=identicon&s=25 James Byrne (byrnejb)
on 2008-12-16 19:30
Robert Walker wrote:
> I think a better question is, "Why isn't there a :dependent => :deny
> option?"

Because Josh said no.

http://dev.rubyonrails.org/ticket/3837
D188e591eac11021329b8821a5f954c7?d=identicon&s=25 Ar Chron (railsdog)
on 2008-12-16 19:52
> Department
>   has_many :employees, :dependent => :deny

has_many :employees, :dependent => 'something'

indicates what non-default behavior to apply to the :employees...  not
some behavior related to the :department

we already have a :before_destroy callback to serve your purpose, which
is far more powerful -- not every case is as simple as "Don't delete if
there are any employees"
280b78a61a968391b7e07e912be102a8?d=identicon&s=25 Robert Walker (robert4723)
on 2008-12-16 20:12
James Byrne wrote:
> Robert Walker wrote:
>> I think a better question is, "Why isn't there a :dependent => :deny
>> option?"
>
> Because Josh said no.
>
> http://dev.rubyonrails.org/ticket/3837

That's a good answer, I'll accept that.

Ar Chron wrote:
> we already have a :before_destroy callback to serve your purpose, which
> is far more powerful -- not every case is as simple as "Don't delete if
>there are any employees"

This also makes sense. Especially in the context of Rails. Having a
"deny delete" or "protect from delete" as implemented in other
frameworks I've used also makes sense in their own right. But, it is
true that this is more a validation issue than an association issue, so
also makes sense to be implemented in the context of validation. The
line can get a bit fuzzy when talking about "relational integrity" since
it takes both association manipulation (cascade delete and nullify) and
validation (deny delete) in order to fully implement.
This topic is locked and can not be replied to.