I'm migrating my Oracle database to MariaDB, and I am unsure how to create a self-referencing ID on one of my tables.
Essentially, if a belongs_to_id is not specified, it will assume that it belongs to itself (and be the same as the ID generated ON INSERT); however, if a belongs_to_id has been specified, then it will use that instead.
The reason I do this is because I have posts and replies stored in the same table. If the id = belongs_to_id then it's an initiating post, whereas if it differs, it is a reply to another post.
I've thought about letting my application (Node JS) do a quick UPDATE using last_insert_id - but it seems rather messy and I'd like to avoid that if possible.
Here's what I use in Oracle - does anyone know how I replicate this in MariaDB please?
CREATE OR REPLACE TRIGGER my_trigger
BEFORE INSERT ON my_table
FOR EACH ROW
BEGIN
:new.id := my_sequence.NEXTVAL;
:new.belongs_to_id := NVL(:new.belongs_to_id,:new.id);
END;
/
This should work in MariaDb as it closely conforms to SQL-99 syntax.
CREATE OR REPLACE TRIGGER my_trigger
BEFORE INSERT ON my_table
FOR EACH ROW
BEGIN
:new.id := my_sequence.NEXTVAL;
:new.belongs_to_id := NVL(:new.belongs_to_id,:new.id);
END;
IF you set your new ID to be an auto increment then you can only use an after insert trigger. Something like
CREATE OR REPLACE TRIGGER my_trigger
AFTER INSERT ON my_table
FOR EACH ROW
v_id NUMBER:
BEGIN
v_id := LAST_INSERT_ID();
:old.belongs_to_id := NVL(:old.belongs_to_id,v_id);
END;
Maybe simply
When INSERTing, set belongs_to_id to NULL (no TRIGGER).
When SELECTing, do COALESCE(belongs_to_id, id).
Meanwhile, completely switch from SEQUENCE to AUTO_INCREMENT (again no TRIGGER).
Related
Trigger under question is for Table which has ETL in ODI but user also has option to edit certain **columns **
if they want to adjust them. This is done using APEX
Trigger is used to change two columns : Changed_by and Change_on.
Both indicating Changes done on APEX PAGE only.
The issue comes when ODI load is run and is MERGE INSERT UPDATE , Trigger thinks its updating and changes the above two columns to "NULL" as its a manual update done by ODI and not on APEX.
Solution
For each Editable Column, there should be a logic which checks NEW: <> :OLD, but as i have 15 columns need to write a lot of code.
Are there others way to achieve this ?
create or replace TRIGGER DW.TRG BEFORE
UPDATE ON DW.TABLE
REFERENCING
NEW AS new
OLD AS old
FOR EACH ROW
BEGIN
IF updating THEN
SELECT
SYSDATE,
v('APP_USER')
INTO
:new.changed_on_dt,
:new.changed_by
FROM
dual;
END IF;
END;
Check if an apex session exists for the current database session and only execute when it is the case.
create or replace TRIGGER DW.TRG BEFORE
UPDATE ON DW.TABLE
REFERENCING
NEW AS new
OLD AS old
FOR EACH ROW
BEGIN
IF SYS_CONTEXT('APEX$SESSION','APP_SESSION') IS NOT NULL AND updating THEN
:new.changed_on_dt := SYSDATE;
:new.changed_by := SYS_CONTEXT('APEX$SESSION','APP_USER');
END IF;
END;
Notes
avoid the SELECT FROM DUAL, you can just assign the values in the trigger.
The "V" functions are pretty slow. For a while there have been sys_context settings that store the session and user data. Those are a lot faster than a function call to the "V" function.
You could make it so that it never overwrites a non-null value with a null one:
IF v('APP_USER') IS NOT NULL
THEN
:new.changed_by := v('APP_USER');
:new.changed_on_dt := SYSDATE;
END IF;
I created a trigger to manage the auto_increment but for the reason that I do not know it always shows me this error: maximum number of recursive SQL levels (50) exceeded.
CREATE OR REPLACE TRIGGER auto_increment BEFORE INSERT ON people FOR EACH ROW
DECLARE
mat number;
namm varchar(40);
coun number;
BEGIN
namm:=:new.name;
IF inserting() THEN T
SELECT COUNT(*) INTO coun FROM people;
IF coun = 0 THEN
INSERT INTO people VALUES(100,namm);
ELSE
SELECT MAX(:old.matricule+1) INTO mat FROM people;
INSERT INTO people (matricule,name) VALUES(mat,namm);
END IF;
END IF;
END;
It is recursive because every time a record is inserted into PEOPLE your trigger inserts another record into PEOPLE, which causes the trigger to fire and insert yet another record into PEOPLE, which... well you get the idea.
In an Oracle trigger you just set the :NEW values to change what is being inserted e.g.:
:NEW.matricule := 100;
However, your trigger still would not work because it selects from the same table, which will cause the "table is mutating" exception.
Really the best answer here is to use a sequence - they are designed to avoid these issues as well as giving the best performance. But if you really need this increment functionality, do it before inserting not in a trigger.
This might appear a simple query for most of you, but I am a beginner in Oracle DB.
A table has been created with below script-
CREATE TABLE PLAN_TABLE
(
PL_ID DECIMAL(10,0) PRIMARY KEY NOT NULL
,PL_NAME VARCHAR2(300) DEFAULT NULL
,UPDATED_TS TIMESTAMP DEFAULT SYSDATE NOT NULL
,DELETE_FLAG DECIMAL(10,0) DEFAULT 0 NOT NULL
);
The requirement is to have SYSDATE for UPDATED_TS for any new record inserted into the table and also in case when the DELETE_FLAG is updated to 1. Can it be done by trigger?
The below trigger was created-
CREATE OR REPLACE TRIGGER PT_BEFORE_INSERT_TR
BEFORE INSERT ON PLAN_TABLE
FOR EACH ROW
BEGIN
SELECT SYSDATE INTO :new.UPDATED_TS FROM DUAL;
dbms_output.put_line('Inserted');
END;
/
Below error was encountered while inserting record into the table-
error: ORA-04091: table I60_SCH04.PLAN_TABLE is mutating, trigger/function may not see it
Can you please help in letting me know that where am I committing the mistake? Is there any better way to achieve the requirement based upon INSERT/UPDATE?
The actual error you get is due to the fact that you try to select from a table that you actually are changing. To prevent the issue there are a couple of methods, but in you case things are really simple.
SYSDATE is a function, that you could call directly inside PL/SQL block (which a trigger actually is) and use the value returned to update the set the column value
CREATE OR REPLACE TRIGGER PT_BEFORE_INSERT_TR
BEFORE INSERT ON PLAN_TABLE
FOR EACH ROW
BEGIN
:new.UPDATED_TS := sysdate;
dbms_output.put_line('Inserted');
END;
/
OK, this covers the insert part.
For updating - once again, many options. One could be - change your trigger to BEFORE INSERT OR UPDATE ON PLAN_TABLE.
In this case whenever you issue update or insert - this trigger is fired for each row and updates the date column accordingly.
And of course you could use particular checks available in triggers, something like
IF INSERTING OR UPDATING('DELETE_FLAG') THEN
...
END IF;
and code in the logic you need.
declare
tgl RENC_DITSEK.TGL_INPUT%TYPE;
thn varchar(10) := :new.tahun + 1;
target RENC_DITSEK.TARGET_2%TYPE;
BEGIN
select TARGET_2 into target from RENC_DITSEK where KODE_RENCANA = :NEW.KODE_RENCANA;
SELECT TO_CHAR(SYSDATE, 'DD/MM/YYYY HH24:MI:SS') INTO tgl FROM DUAL;
IF UPDATING ('TARGET_2') THEN
INSERT INTO NOTE_LOG VALUES(:NEW.PKP,'',:NEW.INDIKATOR,'Target Tahun '||thn,'',:new.target_2,**target**,tgl,'','0');
END IF;
END;
hi, there is my trigger body. i need a value of TARGET_2 before it updated, but i have no ide to do that. so this is my code, but it error "mutating table". is there a way to do that? please help.
thanks for helping.
it would help if you provide the table and the trigger definitions.
e.g. what table are you creating the trigger on? Is KODE_RENCANA the primary key of the table?
If the answer to the above questions is Yes, then you don't need to execute a SELECT statement, since you could get the value of TARGET_2 using :OLD.TARGET_2 for the record you're updating.
If KODE_RENCANA is not the primary key, and it is actually a field that could be updated, and you want to retrieve another record in the same table given the new KODE_RENCANA value, then the problem is more complicated, which I would not recommend using a trigger to handle, instead, try creating a stored procedure and call the stored procedure to perform the update.
cheers.
I have created trigger TEST_TRIG as below:
CREATE TRIGGER TEST_TRIG
AFTER INSERT ON TEST_TABLE
FOR EACH ROW
DECLARE
PRAGMA AUTONOMOUS_TRANSACTION;
BEGIN
TEST_PROC();
END;
Procedure TEST_PROC code:
create or replace
PROCEDURE TEST_PROC
AS
BEGIN
EXECUTE IMMEDIATE 'truncate table TEST_FINAL';
INSERT INTO TEST_FINAL select * from TEST_TABLE;
commit;
END;
Initially, I disabled TRIGGER TEST_TRIG and inserted a record into TEST_TABLE and executed PROCEDURE TEST_PROC manually.
Output: I was able to fetch the same record what i inserted into TEST_TABLE from TEST_FINAL.
I flushed those records from both table and enabled the trigger TEST_TRIG.
Now when i inserts and commits the record in TEST_TABLE, I didn't found the record in TEST_FINAL table... I haven't received any error message also!!!
So I want to know whether trigger got fired or not?
I don't think you have fully grasped the implications of AUTONOMOUS_TRANSACTION. Effectively it means the code bounded by the pragma runs in a separate session . So, because of Oracle's read consistent isolation level, the autonomous transaction cannot see any of the data changes generated by the main transaction.
Thus, if TEST_TABLE is empty when you start the trigger will insert no rows into TEST_FINAL, regardless of how many rows you're inserting right now.
So: don't flush both tables. Insert some rows into TEST_TABLE and commit. TEST_FINAL will still be empty. Insert some more rows into TEST_TABLE and, lo! the first set of rows will appear in TEST_FINAL.
Obviously this is not the result you want. So you need to revisit your logic. It really doesn't make sense to truncate TEST_FINAL every time and definitely not FOR EACH ROW. That is Teh Suck! as far as performance goes. Likewise and for the same reason it doesn't make sense to populate the target table with INSERT ... SELECT .
Discarding the TRUNCATE means you don't need the pragma and everything becomes much simpler,
If you want to keep a history of the affected rows use something like this instead:
CREATE TRIGGER TEST_TRIG
AFTER INSERT ON TEST_TABLE
FOR EACH ROW
BEGIN
insert into test_final (col1, col2)
values (:new.col1, :new.col2);
END;
You'll need to change the exact code to fit your exact requirements.