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.
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.
Robert Walker wrote:
I think a better question is, "Why isn't there a :dependent => :deny option?"
Because Josh said no.
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 Byrne wrote:
Robert Walker 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.
