Allow for dependent nullify to happen on soft destroy #117
Conversation
Braden-077
requested review from
timirwin,
calebwoods,
BenEinwechter,
mark-kraemer,
wesrich,
OutlawAndy,
justwiebe and
johncalvinyoung
Braden-077
changed the title
| @@ -70,9 +70,20 @@ def restore! | |||
| restore(deleted_at) || raise_validation_errors | |||
| end | |||
|
|
|||
| def cascade_soft_destroy_nullify | |||
There was a problem hiding this comment.
Hmm, this would come in handy for a specific case in Gimme Credit https://github.com/RoleModel/gimme-credit/pull/495/files
Is there a reason you aren't checking belongs_to and has_one associations?
@BlaineIrvin perhaps we should use this pattern in Gimme Credit?
There was a problem hiding this comment.
@justwiebe No, the has_one would be another good one to include!
I'm curious why we'd need to do anything to our belongs_to, could you explain that one?
There was a problem hiding this comment.
belongs_to might be an even bigger edge case, but for our situation, we've got a chain of reports that "replace" the previous one. We disallow soft destroying a report in the middle of the chain to side step complications, but we do allow soft destroying the latest report. To keep the chain linear, we decided to remove the soft destroyed one from it altogether be removing the belongs_to association
There was a problem hiding this comment.
It sounds like you're having the child class nullify its own association. There could CERTAINLY be value in that one!
There was a problem hiding this comment.
That sounds like an after_soft_destroy :nullify_self
There was a problem hiding this comment.
I'm not sure that belongs_to would fit into this pattern, since it looks like it can't be dependent nullify, only delete, destroy, and destroy_async.
There was a problem hiding this comment.
Well sure, maybe not out of the box. You could use an arbitrary value on that dependent call. 😉
There was a problem hiding this comment.
@justwiebe @BlaineIrvin Thinking back on this - I'm going to add the has_one update. I think the specific case of the parent record might be best solved by touching the parent record.
Braden-077
force-pushed
the
nullify-soft-destroy-cascade
branch
from
828c7c6 to
db9e566
Compare
Why?
This PR adds the cascade effect to dependencies with
dependent: :nullifyby nullifying the dependency on soft destroy.Note: this is an opt-in behavior, pulled from a specific use case within RoleModel. It's a draft for the moment just to see if this is worth pulling in.
What Changed