Extensible orphan_strategy

[kbrock]

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)
• There is a gotcha requiring them to define it first. Requires a bunch of documentation (red flag)
• Defining your own before_destroy seems simple.
• Avoiding the build the callback gook would be nice. Maybe leaving this code as is but not documenting it may be a plan as well.
• I don't like people knowing about and overriding apply_orphan_strategy, but maybe it is not so bad.

As a developer, what is your take?

---

Turning orphan strategy handling off

class ModelBefore
  def apply_orphan_strategy # no longer necessary with :none
    # skip
  end
  has_ancestry orphan_strategy: :none
end

class ModelAfter
  has_ancestry orphan_strategy: :none
end

Implementing a custom orphan strategy

module CustomStrategy
  def apply_orphan_strategy_abc
    # custom goodness
  end
end

class ModelAfter1
  includes CustomStrategy
  has_ancestry orphan_strategy: :abc
end

class ModelAfter2
  includes CustomStrategy
  before_destroy :apply_orphan_strategy_abc
  has_ancestry orphan_strategy: :none
end

[brendon]

Looks pretty good. Just a couple of suggestions there :D

[brendon]

Could you just compare with the symbol to avoid calling to_s?

[brendon]

This might need a little expansion so that people know they don't need to add their own before_destroy block here. Perhaps:

Your custom destroy strategy method named with the convention apply_orphan_strategy_#{String} will be executed as an before_destroy callback.

[kbrock]

Yea, After trying to document this had me wanting to drop the feature apply_orphan_strategy_#{string} and just have the person write a before_destroy

[brendon]

Yea that makes sense :)

[kbrock]

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.

[kbrock]

update:

• Removed documentation around custom strategies. Just supporting none for now.
• Reworked wording in readme around has_ancestry options.
• rebased to fix conflict

[kbrock]

update:

• handle alternate ancestry column names in custom ancestry test

[brendon]

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 :)

[kbrock]

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)

[brendon]

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

[kbrock]

@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.