Converting a delete statement using VPD policies and context

Question

Hello,
I'm trying to convert a delete statement in a update statement using VPD policies and context.
+/* Supose the user 'user1' already exists. This is an application user */+
conn user1/pwd
create table user1.test_a (
id                number(4),
description       varchar2(100),
deleted           number(1)
+);+
alter table user1.test_a add constraint test_a_pk primary key (id);
insert into user1.test_a (1, 'abc', 0);
insert into user1.test_a (2, 'def', 0);
commit;
I'd like to convert each physical deletion into a logical deletion: statements like "delete from user1.test_a where id = 1" must be converted into "update user1.test_a set deleted = 1 where id = 1".
I've found the following way: I will create a policy to avoid physical deletion. Additionally, the policy function should update the deletion flag too.
conn user1/pwd
+/* Create context package */+
create or replace package user1.pkg_security_context is
procedure p_set_ctx(
i_test_a_id      in   user1.test_a.id   %type
+);+
end;
+/+
create or replace package body user1.pkg_security_context is
procedure p_set_ctx (
i_test_a_id      in   user1.test_a.id   %type
+) is+
begin
dbms_session.set_context( 'user1_ctx', 'test_a_id', i_test_a_id );
end;
end;
+/+
show errors
+/* Create trigger to set the context before deletion */+
create or replace trigger user1.test_a_bef_trg
before delete on user1.test_a
for each row
declare
pragma autonomous_transaction;
begin
-- only commits the preceding update, not the delete that fired the trigger.
commit;
user1.pkg_security_context.p_set_ctx( :old.id );
end;
+/+
show errors
create context user1_ctx using user1.pkg_security_context;
+/* Policy function */+
create or replace function user1.f_policy_chk_dels (
object_schema in   varchar2,
object_name   in   varchar2
+) return varchar2+
is
out_string                 varchar2(400)   default '1=2 ';
+/*+
* out_string is the return value.
*  - 'WHERE 1=2' means 'nothing to access'
begin
if ( loc_logged_usr_authorized > 0 ) then
+/*+
* Set the flag deleted to 1
update user1.test_a set deleted = 1 where id = sys_context( 'user1_ctx', 'test_a_id' );
out_string := out_string || 'or 1=1 ';
end if;
return out_string;
end;
+/+
show errors
+/*+
* Create policy
begin
dbms_rls.add_policy(
object_schema   => 'user1'                   ,
object_name     => 'test_a'                  ,
policy_name     => 'policy_chk_dels'         ,
function_schema => 'user1'                   , -- function schema
policy_function => 'f_policy_chk_dels'       , -- policy function
statement_types => 'DELETE'
+);+
end;
+/+
When I try to delete a record of the table test_a:
conn user1/pwd
SQL> delete from ilogdia.oplsimulaciones sim       where sim.id = 9999;
+0 rows deleted+
No rows has been deleted, but the update stmt does not work. That means, the "deleted" flag has not been updated.
Any ideas?
Thank you in advance.
Marco A. Serrano
Edited by: albrotar on Oct 15, 2012 8:42 AM
Edited by: albrotar on Oct 15, 2012 8:42 AM
Edited by: albrotar on Oct 15, 2012 8:43 AM

Answer 1

The policy function is applied once per statement execution. The policy function executes first and the UPDATE statement, presumably, updates no rows because the context is not yet populated. The row-level populates the context (I'm assuming that your session can even see context values populated by an autonomous transaction-- I would guess it could but I'd have to test that) after the UPDATE statement is already complete. The COMMIT in the row-level trigger is also pointless-- it only applies to changes made by the current autonomous transaction, of which there are none-- it cannot apply to changes made in other autonomous transactions. Declaring the row-level trigger to use autonomous transactions doesn't seem to accomplish anything other than to open the question of whether the values set in the context by the autonomous transaction are visible in the caller's transaction.
Even if this, somehow, did work, using autonomous transactions would be a very bad idea since Oracle is free to roll-back a partially executed statement (and the work done by its triggers) and re-execute it. Oracle does that with some regularity to maintain write consistency.
Justin