Skip to Main Content
Feature Request FR-3332
Product Area SQL Workshop
Status CLOSED

12 Voters

QuickSQL should only generate compound triggers

rich soule Public
· Aug 29 2023

Idea Summary
Right now QuickSQL generates non-compound triggers with names like “employees_biu” (employees before insert update) leading folks down the path of creating another trigger like “employees_aiu” (employees after insert update). Generally a table should really only have a single trigger (yes, if you are using Edition Based Redefinition you'd have two triggers). Since compound triggers were introduced in Oracle 11g, that single trigger should be a compound trigger. 

Use Case
Compound triggers have many advantages over multiple triggers including global declarations and a specific firing order, but by far the biggest advantage is a single place to look for trigger logic.

When a trigger in QuickSQL is generated, it should look something like the below:

create or replace trigger <trigger-name> --example: employee_compound_trigger
  for insert or update or delete on <table-name>
    compound trigger

  -- global declarations
  -- g_global_variable varchar2(10);

  before statement is
  begin
    null; -- do something here.
  end before statement;

  before each row is
  begin
    null; -- do something here.
  end before each row;

  after each row is
  begin
    null; -- do something here.
  end after each row;

  after statement is
  begin
    null; -- do something here.
  end after statement;

end <trigger-name>;
/
We reviewed this idea carefully, and while it was interesting, we concluded that due to all the internal implications we need to take into account, it is unlikely to make its way into APEX.

Comments

Comments

  • jayson hanes Admin OP 1.8 years ago

    why “should”? I like separate triggers. Now what?

  • rich soule OP 1.8 years ago

    Jayon “I like horses, cars are overrated” Hanes asked “Why “should”? I like separate triggers. Now what?”

    /smile

    Why would you like separate triggers?

    From OracleBase.com (in 2011, as in 12 years ago…):

    Oracle allows you to have multiple triggers defined for a single timing point, but it doesn't guarantee execution order unless you use the FOLLOWS clause available in Oracle 11g, described here.

    With the exception of Compound Triggers, the triggers for the individual timing points are self contained and can't automatically share state or variable information. The workaround for this is to use variables defined in packages to store information that must be in scope for all timing points.

    In my opinion, there are no benefits at all to using separate triggers, only detriments.

    If you really, really want the ability to have QuickSQL generate separate triggers, you could, generate compound triggers by default (as one should ;) ) and provide an option of “Add complexity to our implementation by implementing triggers as separate triggers, but realize that if you need to share state or variable information between those triggers you'll have to put that information into packages that will need to be in scope for the triggers”. Or you could just label it “Use legacy triggers”.

    So, if you want to update this idea to read “QuickSQL should also have the ability to generate compound triggers” I'm on board. It's all good.

    BTW, thanks for the awesomeness that is APEX and QuickSQL. You and the team give us great stuff and we love it!

  • steven.feuerstein OP 1.8 years ago

    I love this idea - compound triggers have been around since 11g. 

    Basically, if you agree that all procs and funcs should be inside packages and not “stand-alone”, the very same argument applies to individual triggers vs compound.

    However, it should be “also” not “instead”. Make the default compound and let the user revert to individual triggers

  • jayson hanes Admin OP 1.6 years ago

    QuickSQL has grown in popularity and to expand that growth it is now in a standalone Git Hub Repository accessed here https://github.com/oracle/quicksql.  ORDS 23.3+ ships with the latest version of QuickSQL which is then used in APEX. Issues and Enhancements should be directed to the git repository.