Closed kbrock closed 1 year ago
Ok, so this stalled.
I think that introducing none
makes sense while introducing a naming strategy is too much.
The issues with making sure the method is defined first and the difficulty in documentation makes me feel that this is not ready yet.
I will keep this PR intact, and create another PR to introduce none
The naming strategy code is smaller and simpler.
Not ready to support the strategy yet, but leaving the code in there.
update:
has_ancestry
options.update:
Looks good :) When I'm upgrading next, I'll give it a go. It might be that the custom orphan strategy would need to be defined immediately after has_ancestry
to ensure callbacks are still in the correct order in some apps :)
Actually, the custom method needs to be defined before the has_ancestry
.
So just adding an include
or subclassing a model would work.
But in looking through github, the overrides for this method were almost all to disable it. There was one that moved this to a background task. (was thinking of changing these methods to pass an object, but the reliance on changed makes it tricky)
I think in my case it was the order of deletion but I think that was also fixed recently so I might not need the custom method anyway. I've not started moving to Rails 7 yet but when I do, this gem will get upgraded :D
@brendon Thanks. That info helps me.
Someone asked about when this will ship. I'm probably going to backport this, as I am making (slow) progress towards converting many functions to sql only.
This introduces 2 ways for developers to extend the built in orphan strategies.
Fixes #142
/cc @brendon Here is custom orphan strategies.
After implementing this, I'm thinking of keeping
:none
and dropping the custom string.none
is straightforward and simple to document. The custom one is much harder (red flag)before_destroy
seems simple.apply_orphan_strategy
, but maybe it is not so bad.As a developer, what is your take?
Turning orphan strategy handling off
Implementing a custom orphan strategy