Project

General

Profile

Feature #4076

remove empty triggers during conversion

Added by Greg Shah about 5 years ago. Updated about 3 years ago.

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

0%

billable:
No
vendor_id:
GCD
version_reported:
version_resolved:

History

#1 Updated by Greg Shah about 5 years ago

One of our customers adds trigger procedures for every permanent database table, even if the trigger is empty. In fact, many of these triggers are empty. They are there in case someone wants to add something later. In such a scenario, no schema changes are needed. The program can simply be edited and updated in source control.

The down side is that there are a very large number of extra triggers implemented, which will certainly have a performance cost in both the original and FWD systems.

The customer asked if we can remove empty triggers during the conversion. Of course we can, it is just a matter of effort. They are specifically asking about schema triggers, but the concept really applies to all trigger types.

This will work fine so long as there are no side-effects of invoking an empty trigger. Or at least as long as there are no side effects upon which the application can rely.

The implementation would have to handle the following:

  • Detecting
    • For UI triggers and session-level DB triggers, we would look at the contents of TRIGGER_BLOCK/BLOCK/ and make sure that there are no child nodes.
    • For schema triggers, the entire external procedure must be empty except for the TRIGGER_PROCEDURE statement, which must be ignored.
    • We should do this calculation in annotations/early_annotation.xmls, leaving behind an annotation with the result.
    • We should add reports using this annotation.
  • Bypassing
    • For UI triggers and session-level DB triggers, I think we can hide the associated ON statement in annotations.
    • Schema triggers will probably require a bit more work.
      • Optimally, we would ignore these completely and not generate a resulting class.
      • We will definitely need to avoid registering these as part of the conversion.

Can anyone think of a reason this won't work?

What other implementation details or issues do we need to consider?

#2 Updated by Ovidiu Maxiniuc about 5 years ago

From the POV of schema triggers only: yes, this should work.

I have a question. We can detect if the trigger file is empty quite early, in fixups. Are we able to put a file on 'ignore' and not process it in any way (annotation/convert/brew) after this?

#3 Updated by Greg Shah about 5 years ago

I have a question. We can detect if the trigger file is empty quite early, in fixups. Are we able to put a file on 'ignore' and not process it in any way (annotation/convert/brew) after this?

Yes, I was thinking of this approach as well. We could implement some kind of registry for the ignore list and then the ConversionDriver would need to refresh its list of files in between each execution of the PatternEngine.

The processing of the schema triggers would still need to be made safe so that we don't complain about a missing trigger procedure if it is empty. But otherwise, I guess the approach would be pretty safe.

#4 Updated by Ovidiu Maxiniuc about 3 years ago

In my initial implementation of schema triggers, the linking between the event and the invoked trigger class/method was decided at conversion time. Recently, Adrian added support for resolving the trigger procedure/class at runtime, based on PROPATH system variable, as OE does. This means that the programmer can change the active trigger for a table/field by simply changing the order of paths inside the variable.

This makes me think of a scenario where some programmer/hacker use two different triggers (with same name). S/He can dynamically suspend the trigger by raising priority of the path with empty triggers. If we detect and drop these, then the lookup will continue searching past the expected path and find and use the next matching trigger. Maybe I am too evil-ish but a similar scenario can happen when an unexpected procedure is called because the designed NO-OP procedure was removed.

The UI triggers do not pose this problem since they are hardcoded in the converted source.

#5 Updated by Greg Shah about 3 years ago

Maybe I am too evil-ish but a similar scenario can happen when an unexpected procedure is called because the designed NO-OP procedure was removed.

No, you are not being evil. I agree it is a real issue.

OK, I think there is still a way we can make this better. We have to resolve the empty triggers. Perhaps we could emit a method override public boolean isEmpty() { return true; } which can report that should bypass execution. A parent class can implement public boolean isEmpty() { return false; }. Is there any reason this would be an issue?

My idea is that at least we will avoid a bunch or setup and tear-down for no reason. On the other hand, if there is some side-effect for executing an empty trigger, then we may need to execute it after all.

Also available in: Atom PDF