On Thu, Feb 16, 2023 at 10:43 AM Dominique Devienne <ddevie...@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. David J.