UPDATE CASCADE PACKAGE
Generates needed package and triggers to support update cascade in Oracle
without removing or infringing on DECLARITIVE RI.
This package supports:
- Tables with multi-part primary keys (primary key(a,c,b))
- Update cascade to many child tables from one parent
- Self-referencing integrity such as that found in the SCOTT.EMP table
(mgr->empno)
- Is completely application transparent. The application does not know it is
happening
- Versions 7.0 and above of the database.
- Tuned and optimized to fully avoid full table scans on all tables (complete
with utility to show you un-indexed foreign keys in a schema, Cascading an
update to un-indexed foreign keys can be bad).
This solution has the
following restrictions:
- All foreign keys to the parent table must point to the primary key
constraint of the parent table. They cannot point to a unique constraint on
the parent table, they must point to the primary key.
- No other unique constraints/indexes may be in place on the parent
table other then the primary key constraint.
- Updates to primary keys that do not generate 'new' primary keys are not
currently supported. For example, take the standard DEPT table. The update
statement
"update dept set deptno = deptno+10" will not work
whereas the update "update dept set deptno = deptno+1" will. The
first update will change 10->20, 20->30 and so on. Problem is that
10->20 is not generating a 'new' primary key. On the other hand,
deptno=deptno+1 does not have this problem since 10->11, 20->21 and so on.
NOTE: an update that affects a single row will never suffer from this
problem.
- the owner of the parent table must also be the owner of the child tables.
- the owner of the parent table must run the following package in their
schema. This package must be installed for each user that wants to generate
update cascade support. It may be dropped after the cascade support has been
generated.
- the owner of the parent table must have been granted create procedure and
create trigger. these priveleges may not be inherited from a role.
Installing, Using, and seeing how the demo works
This package consists of four SQL scripts
- uc.sql
- demobld.sql
- unindex.sql
- generate.sql
UC.SQL
UC.SQL should be run by any user wanting to implement update
cascade. It will create
- A package spec for update_cascade
- A package body for update_cascade
Once this package is installed,
you are able to implement update cascade on any table via the pl/sql call:
PROCEDURE update_cascade.on_table
Argument Name Type In/Out Default?
------------------------------ ----------------------- ------ --------
P_TABLE_NAME VARCHAR2 IN
P_PRESERVE_ROWID BOOLEAN IN DEFAULT
P_USE_DBMS_OUTPUT BOOLEAN IN DEFAULT
| Input Name |
Default |
Usage |
| p-table-name |
NO DEFAULT |
is the name of the parent table |
| p-preserve-rowid |
TRUE |
affects the generation of the code used to implement the generated packages.
If set to TRUE (the default) the rowid of the updated parent row will not change
due to the update. If set to FALSE, the rowid of the updated row WILL change BUT
the code executes in about 66% of the time. |
| p-use-dbms-output |
FALSE |
defaults to FALSE which means the update_cascade package will execute
(create) the packages/triggers. If set to true, the generated code will be
printed using dbms_output.put_line (make sure to set serveroutput on size 100000
before using TRUE if you want to see the code).
|
For example....
SQL> REM will do the default cascade support on
SQL> REM the dept table
SQL> REM ROWIDS will be preserved (unchanged).
SQL> REM Package will be created in the database
SQL> exec update_cascade.on_table( 'dept' )
SQL> REM will do the same as above but will not
SQL> REM preserve the rowids of the parent table
SQL> REM (the rowids will change). This version
SQL> REM runs in about 2/3 of the time of the first
SQL> REM one
SQL> exec update_cascade.on_table( 'dept', false )
SQL> REM will do the same as above but will not
SQL> REM preserve the rowids of the parent table
SQL> REM (the rowids will change). This version
SQL> REM runs in about 2/3 of the time of the first
SQL> REM one. Also, the packages will be written
SQL> REM to the SCREEN, not into the database.
SQL> exec update_cascade.on_table( 'dept', false, true )
The above would generate and compile all of the packages/triggers need to
support cascading updates on the dept table to any other table. You would run
this any time you
- changed the primary key definition of the dept table
- added a child table to the schema (eg: executed a create table and that
table points to dept)
- removed a child table from schema
NOTE: The user executing
update_cascade must have been granted
- CREATE TRIGGER
- CREATE PROCEDURE
directly to themselves. They cannot just have the
privilege via a role.
The other mode of calling update_cascade.on_table is as follows:
SQL> set feedback off
SQL> spool tmp.sql
SQL> exec update_cascade.on_table( p_table_name => 'dept', p_use_dbms_output =>TRUE )
SQL> spool off
The above would generate and
print (as opposed to compile) all of
the packages/triggers/views needed to support cascading update on the dept table
to any other table. You would use this mode to
- Avoid having to grant CREATE VIEW, CREATE TRIGGER, CREATE PROCEDURE directly
to the person (they can get these priveleges via a role like DBA).
- To inspect the generated code to understand what it does.
- To generate a package that can be used to install update cascade support at
another site without giving them the update_cascade package itself.
The other mode of calling update_cascade.on_table is as follows:
SQL> exec update_cascade.on_table( p_table_name => 'dept', p_preserve_rowid =>FALSE )
The above would generate
faster versions of the udpate
cascade packages. They run in 2/3 of the time of the default version but the
rowid's of the updated parent records will change.
This makes this version
less desirable with FORMS. If you use forms heavily, use the default mode so
that rowids are preserved. The triggers to cascade can get away with a lot less
work in this mode. The triggers fire half the time they would in the default
mode and an update that would normally fire and affect 2x the number of rows is
not needed. The generated package code is streamlined as well (less actuall code
is generated, procedural code not just updates).
DEMOBLD.SQL
This script creates one user and three tables in that users
schema. The user is called UCDEMO.
WARNING: This script does a "drop user
ucdemo cascade". It is run as SYSTEM. Please review it before running it. Modify
if you want. Once the script creates the user it will create six tables and
populate them. The tables are:
- DEPT with a primary key
- EMP with a primar key, DECLARATIVE RI to DEPT, DECLARATIVE RI to EMP
- PROJECTS with a primary key, DECLARATIVE RI to EMP
- T1 with a three part primary key
- T2 with a three part primary key and a three part foreign key to T1
- T3 with a three part primary key and a three part foreign key to T2
To begin the demo, you might issue:
SQL> update dept set deptno=deptno+1;
update dept set deptno=deptno+1
*
ERROR at line 1:
ORA-02292: integrity constraint (UCDEMO.SYS_C005184) violated - child record
found
Then to see the update cascade in action, you would:
SQL> @uc
Table created.
Table altered.
Package created.
Package body created.
SQL> exec update_cascade.on_table('dept');
PL/SQL procedure successfully completed.
SQL>
SQL> select * from dept;
DEPTNO DNAME LOC
---------- -------------- -------------
10 ACCOUNTING NEW YORK
20 RESEARCH DALLAS
30 SALES CHICAGO
40 OPERATIONS BOSTON
SQL> select empno, deptno from emp where deptno = 10;
EMPNO DEPTNO
---------- ----------
7839 10
7782 10
7934 10
SQL> update dept set deptno = deptno+1;
4 rows updated.
SQL> select * from dept;
DEPTNO DNAME LOC
---------- -------------- -------------
11 ACCOUNTING NEW YORK
21 RESEARCH DALLAS
31 SALES CHICAGO
41 OPERATIONS BOSTON
SQL> select empno, deptno from emp where deptno in ( 10, 11 );
EMPNO DEPTNO
---------- ----------
7839 11
7782 11
7934 11
SQL>
As you can see, after the package is installed, the updates cascade
successfully to the child tables. The effect of this is even more dramatic when
you do it to the emp table. The MGR column of the EMP table points to the EMPNO
column of the EMP table. In addition, the EMPNO column of the PROJECTS table
points to the EMPNO column of the EMP table. The following scenario is a good
demo of more complex integrity:
SQL> select empno, mgr from emp;
EMPNO MGR
---------- ----------
7839
7698 7839
7782 7839
7566 7839
7499 7698
7521 7698
7654 7698
7902 7566
7369 7902
7788 7566
7844 7698
7876 7788
7900 7698
7934 7782
14 rows selected.
SQL> update emp set empno = 8000 where empno = 7698;
update emp set empno = 8000 where empno = 7698
*
ERROR at line 1:
ORA-02292: integrity constraint (UCDEMO.SYS_C005186) violated - child record
found
SQL> exec update_cascade.on_table('emp')
PL/SQL procedure successfully completed.
SQL> update emp set empno = 8000 where empno = 7698;
1 row updated.
SQL> select empno, mgr from emp;
EMPNO MGR
---------- ----------
7839
7782 7839
7566 7839
7499 8000
7521 8000
7654 8000
7902 7566
7369 7902
7788 7566
7844 8000
7876 7788
7900 8000
7934 7782
8000 7839
14 rows selected.
UNINDEX.SQL
The lack of an index on a foreign key will adversely impact
the performance of a cascading update. For example, the emp table is created
via:
CREATE TABLE EMP
(EMPNO NUMBER(4) primary key,
ENAME VARCHAR2(10),
JOB VARCHAR2(9),
MGR NUMBER(4) references emp,
HIREDATE DATE,
SAL NUMBER(7,2),
COMM NUMBER(7,2),
DEPTNO NUMBER(2) references dept);
The MGR column and the DEPTNO column are not indexed by default. So, for
example, if one were to issue:
SQL> @unindex.sql
STAT TABLE_NAME COLUMNS COLUMNS
---- ------------------------------ -------------------- --------------------
**** EMP MGR
ok EMP DEPTNO DEPTNO
ok PROJECTS EMPNO EMPNO, PROJ_NO
ok T2 A A, B
ok T3 A, B A, B, C
SQL>
The four **** indicate that MGR is a foreign key in the EMP table that is
not indexed. It should be (also see chapter 6 in the server application
developers guide for other reasons why un-indexed foreign keys are bad).
GENERATE.SQL
This is a simple script that will generate all of the
needed update_cascade.on_table( 'table_name' ) statements that need to be
executed for all parent tables in a schema. For example, in the demo account it
would create a spool file that contains:
SQL> @src="" update_cascade="" generate="" dept="" emp="" t1="" prompt="" update="" cascade="" on="" table:="" execute="" update_cascade.on_table(="" t2="" )="">
HOW it works:
When you update the primary key of a parent table, you might want to cascade the
update to the children. This is hard to do for many reasons and can be
problematic. This package works around the lack of an update cascade option.
This package uses three triggers to perform it magic.
- A before update trigger; used to reset some package variables
- A before update, for each row trigger; used to capture the before and after
images of the primary keys in pl/sql tables. It also 'undoes' the update to the
primary key.
- An After update trigger that does the following steps:
- 'Clones' the parent records with their new primary key, eg: insert into
parent select NEW_KEY, other_cols from parent where CURRENT_KEY = ( SELECT
OLD_KEY FROM DUAL) for example, given "update dept set deptno=deptno+1", this
would insert the values of 11, 21, 31, 41 into the dept table. 11 would have the
values in the rest of the columns that 10 had. 21 would look like 20 and so on.
- If p_preserve_rowids = TRUE, then the primary keys of the row that was
cloned and the clone would be flip flopped. For example, if you issue: update
dept set deptno = 11 where deptno = 10 we would make 10 become the new value 11
and 11 become the old value 10.
- Re-Parents the child records in all subordinate tables. Performs the
equivalent of: update child set fkey = ( select new_key from DUAL ) where fkey =
( select old_key from DUAL )
- It then removes the 'cloned' parent records or the record with the old
primary key value.
A look at the code
The follow annotated code is the generated packages
and triggers you would create by generating support for the dept table.
The following package spec is what would be generated for the typical 'DEPT'
table found in the scott schema (when declaritive RI is used). See the
annotations in the spec for a description of what each entry means and how it is
used. The annotations are not found in the generated code, the generated code is
not commented.
This generated code preserves rowids. The code that preserves rowids will be
in bold. This code would not be present in the generated package if rowid
preservation was disabled.
SQL> exec update_cascade.on_table('dept',true,true);
The following is a typical package specification generated for a table.
The package spec name is always u || TABLE_NAME || p. The package name is in
mixed case (to prevent collisions with other user objects). create or replace package "uDEPTp"
as
--
Rowcnt is used to collect the number of rows processed by a given
update statement. It is reset in the uDEPTp.reset routine in a before update
trigger. The 'inTrigger' variable is used to prevent recursive firing of
triggers when p_preserve_rowid = TRUE; rowCnt number default 0;
inTrigger boolean default FALSE;
--
For each element in the primary key, a table type will be declared and
then an array of that type will be declared to 1.) hold the before image, 2.)
the after image, and 3.) an empty array used to zero out the previous two
arrays. type C1_type is table of "DEPT"."DEPTNO"%type index by binary_integer;
--
empty_C1 C1_type;
old_C1 C1_type;
new_C1 C1_type;
--
--
Reset is the routine fired by the BEFORE UPDATE trigger that resets the
rowcnt variable and empties out the arrays from the previous invocation. procedure reset;
--
Do cascade is the work horse routine. It performs the actual cascade
when fired from an AFTER UPDATE trigger. procedure do_cascade;
--
Add Entry simply increments the rowcnt and collects the before/after
images of the primary keys. It also 'undoes' the update to the primary key by
accessing the :new and :old variables. procedure add_entry
(
p_old_C1 in "DEPT"."DEPTNO"%type
,p_new_C1 in out "DEPT"."DEPTNO"%type
);
--
end "uDEPTp";
/
This is the package body generated. It implements the above specification
create or replace package body "uDEPTp"
as
--
procedure reset
is
begin
--
This line is present in all routines when p_preserve_rowids = TRUE. It
prevents recursive firing of the triggers. if ( inTrigger ) then return; end if;
--
rowCnt := 0;
old_C1 := empty_C1;
new_C1 := empty_C1;
end reset;
--
procedure add_entry
(
p_old_C1 in "DEPT"."DEPTNO"%type
,p_new_C1 in out "DEPT"."DEPTNO"%type
)
is
begin
--
if ( inTrigger ) then return; end if;
--
This code saves the before and after images in pl/sql tables and
'undoes' the primary key update by setting the new columns back to the old
columns. if (
p_old_C1 <> p_new_C1
) then
rowCnt := rowCnt + 1;
old_C1( rowCnt ) := p_old_C1;
new_C1( rowCnt ) := p_new_C1;
p_new_C1 := p_old_C1;
end if;
end add_entry;
--
procedure do_cascade
is
begin
--
if ( inTrigger ) then return; end if;
inTrigger := TRUE;
--
For every row that was updated we will perform the clone, cascade and
delete.... for i in 1 .. rowCnt loop
This insert clones the parent row, duping the old values with the new
primary key. insert into DEPT (
"DEPTNO"
,"DNAME","LOC") select
new_C1(i)
,"DNAME","LOC"
from "DEPT" a
where ( "DEPTNO" ) =
( select old_C1(i)
from dual );
--
This code is generated only when p_preserve_rowids=true and will
flip-flop the old and new primary keys, hence preserving the rowid of the
original parent. update "DEPT" set
( "DEPTNO" ) =
( select
decode( "DEPTNO", old_c1(i), new_c1(i), old_c1(i) )
from dual )
where ( "DEPTNO" ) =
( select new_C1(i)
from dual )
OR ( "DEPTNO" ) =
( select old_C1(i)
from dual );
--
Do a cascade update to all children tables. update "EMP" set
( "DEPTNO" ) =
( select new_C1(i)
from dual )
where ( "DEPTNO" ) =
( select old_C1(i)
from dual );
--
Removing the old primary key value. delete from "DEPT"
where ( "DEPTNO" ) =
( select old_C1(i)
from dual);
end loop;
--
inTrigger := FALSE;
reset;
exception
when others then
inTrigger := FALSE;
reset;
raise;
end do_cascade;
--
end "uDEPTp";
/
Lastly, we have the three triggers placed on the parent table to effect the
update cascade. The first trigger simply 'resets' the package variables above.
create or replace trigger "uc$DEPT_bu"
before update of
"DEPTNO"
on "DEPT"
begin "uc$DEPT_pkg".reset; end;
The next trigger, the for each row trigger, simply calls add_entry for
each changed row. create or replace trigger "uc$DEPT_bufer"
before update of
"DEPTNO"
on "DEPT"
for each row
begin
"uc$DEPT_pkg".add_entry(
:old."DEPTNO"
,:new."DEPTNO"
);
end;
The last trigger, calls do_cascade to effect the change create or replace trigger "uc$DEPT_au"
after update of
"DEPTNO"
on "DEPT"
begin "uc$DEPT_pkg".do_cascade; end;
http://asktom.oracle.com/~tkyte/update_cascade/index.html
all.tar
DemoBld Package.sql
