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.
On Tue, Dec 16, 2008 at 10:29 AM, Ed Lebert [email protected] 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
@Ed:
Just leave the :dependent option off completely and nothing happens to
the other records. That’s the default behavior.
Robert W. wrote:
I think a better question is, “Why isn’t there a :dependent => :deny
option?”
Because Josh said no.
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.
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”
James B. wrote:
Robert W. wrote:
I think a better question is, “Why isn’t there a :dependent => :deny
option?”Because Josh said no.
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.