Project

General

Profile

Support #4376

test replication trigger implementation

Added by Greg Shah almost 7 years ago. Updated 14 days ago.

Status:
New
Priority:
Normal
Assignee:
-
Target version:
-
Start date:
Due date:
% Done:

0%

billable:
No
vendor_id:
GCD
case_num:
version_reported:
version_resolved:
reviewer:
production:
No
env_name:
topics:

History

#1 Updated by Greg Shah 14 days ago

Ovidiu: Can this be closed in light of your work iwth #11383? Are there any gaps we need to consider fixing in the future?

#2 Updated by Ovidiu Maxiniuc 14 days ago

From my knowledge, the replication triggers are on par with the standard database triggers. I found nothing different between these two kind of triggers, except for the order of execution and specific functionality for enabling/disabling them. So the response for the second part is no, there are no known gaps specific to replication trigger to be fixed in the future.

In relation to 11383a: this branch does not address nor interferes with the implementation of triggers. The triggers and callbacks have different support data structures and different triggers. There is not even 1:1 ratio between the number of their execution for a given code. In short, these are two parallel solutions for pretty different problems (to mimic the 4GL triggers and to actually get notified when the records are visible from backing SQL).

But, it is a known issue that the FWD triggers (all of them, maybe with the exception of ASSIGN, when the record is not mandatory about to be flushed) do not match 100% the moments the 4GL are fired. So, at least for this reason, I'd recommend keeping this task open. Is it good enough?

Also available in: Atom PDF