On Thu, Feb 16, 2023 at 10:43 AM Dominique Devienne <ddevienne@gmail.com> wrote:
Are there techniques for situations like this?
This question is not too far from my earlier question, in the sense that a trigger would need to know the context in which it was triggered, i.e. directly (then update the other model), or indirectly (don't update, the change is boomerang'ing around from our own change).
As with the other question - a trigger does not know how the insert/update/delete action came into existence, it is only reacting to the fact that a given row is being added/updated/removed from its table. You might be able to expend a non-trivial amount of effort trying to figure out schemes whereby such information can be inferred but you are fighting the system.
PS: At time point, changing the legacy code base is not really an option...
Then maybe you need to design the new system to behave in a manner similar to the legacy system for the stuff they share in common. You can then have a uni-directional trigger going from legacy to modern.
