"instead of" trigger on a view with a condition

Question

I'm trying to create an instead-of trigger on a view but I want it all such that:
1. It fires only for a certain condition.
2. When the condition isn't met, I want the normal DML on the view to continue as it normally would.
3. I want to avoid writing as much manual DML code as possible for long-term maintainability.
My first attempt is like this:
create or replace trigger PROPOSAL_PARTS_V_IRU
  instead of update on proposal_parts_v
  for each row
  WHEN :old.PART_MASTER_ID <> :new.PART_MASTER_ID
BEGIN
  do_stuff_for_part_master_change;
END;So when the OLD and NEW PART_MASTER_IDs have changed, I want special processing. Else, I want it to do whatever it normally does (let the view get updated and the database will manage the update of the underlying table).
When compiling that I get "ORA-25004: WHEN clause is not allowed in INSTEAD OF triggers".
OK I will accept that even though I want it to work.
So my next attempt could be:
create or replace trigger PROPOSAL_PARTS_V_IRU
  instead of update on proposal_parts_v
  for each row
BEGIN
  IF :old.PART_MASTER_ID <> :new.PART_MASTER_ID THEN
    do_stuff_for_part_master_change;
  ELSE
    UPDATE proposal_parts -- Manually update the underlying table with manually-written DML but I hate having to do this in case the view or table columns change.
    SET...
    WHERE...
  END;So my question is...is there any syntax to do something like this?
create or replace trigger PROPOSAL_PARTS_V_IRU
  instead of update on proposal_parts_v
  for each row
BEGIN
  IF :old.PART_MASTER_ID <> :new.PART_MASTER_ID THEN
    do_stuff_for_part_master_change;
  ELSE
    update_row;
  END;...where "update_row" is some sort of built-in command that tells oracle to continue with the current update as if the trigger never existed.
Back in the day I seem to remember that Oracle Forms had a trigger and syntax like this where you could intercept a DML and if under certain conditions it wasn't true, you could say "update_row" (or maybe it was "update_record?...whatever) and it meant "continue with update as if this instead-of trigger never existed".
Is anything available like that for the DB now? I know in older versions no, but we are now on 11g...anything new come out like this?
Otherwise I have to manually write an update statement and I'd rather not if I don't need to.
Thanks!

Answer 1

riedelme wrote:
gti_matt wrote:
I'm trying to create an instead-of trigger on a view but I want it all such that:
1. It fires only for a certain condition.You can use IF Logic inside a trigger to do or not do anything. As long as it is a condition you can check you can code IF logic around it
2. When the condition isn't met, I want the normal DML on the view to continue as it normally would.You will have to code all of your logic in the INSTEAD of trigger. The whole purpose of the INSTEAD OF trigger is to execute INSTEAD OF performing DML on the view. There is no way to go back to the "normal DML" when the INSTEAD OF trigger exists.
You can put all of the logic you will need in the INSTEAD OF trigger and use IF conditions. Use IF logic to code both your special and "normal" processing.
3. I want to avoid writing as much manual DML code as possible for long-term maintainability.You will have to code the operative lines somewhere. Reusable functions and/or procedures in a package?Yep using an "IF" I knew about...no problem there.
But was just looking for a cheap and easy way to say (for the "else" condition) to revert to normal DML processing. Sounds like in a DB trigger there is no such syntax I guess.
This is an example from Oracle Forms, I was looking for a database equivalent of this(see http://sqltech.cl/doc/dev2000/help/fbhelp18.htm):
Built-in Subprograms for On-Event Triggers For most of the transactional On-event triggers, there is a corresponding built-in subprogram.
On-Event Trigger
Corresponding Built-in
On-Delete
DELETE_RECORD
On-Insert
INSERT_RECORD
On-Update
UPDATE_RECORD
When you call one of these built-in subprograms from its corresponding transactional trigger, Form Builder performs the default processing that it would have done normally at that point in the transaction.
For example, if you call the INSERT_RECORD procedure from an On-Insert trigger, Form Builder performs the default processing for inserting a record in the database during a commit operation.
When these built-ins are issued from within their corresponding transactional triggers, they are known as do-the-right-thing built-ins. That is, they do what Form Builder would normally have done at that point if no trigger had been present. Thus, an On-Insert trigger that calls the INSERT_RECORD procedure is functionally equivalent to not having an On-Insert trigger at all. Such a trigger is explicitly telling Form Builder to do what it would have done by default anyway.Note that the author calls them the "do-the-right-thing" built-ins. That's what I was looking for but on the DB side. Sounds like Oracle didn't come up with that (yet)?