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.

Reply via email to