The second benefit of using the Application Context over Package Functions is that a reference to an Application Context in a where clause is resolved like a bind-parameter and evaluated only once per query, whereas a package function is called over an over again for every record that is evaluated, even if the function returns the same value for every call.

Every VPN-definition is set like:

begin
DBMS_RLS.ADD_POLICY (
object_schema => ‘xxx_OWN’,
object_name => ‘COMPANIES’,
policy_name => ‘RLS_COMPANIES’,
function_schema => ‘SYSBEHEER’,
policy_function => ‘SBR$AUTORISATIE.RLS_autorisatie’
);
end;

The function SBR$AUTORISATIE.RLS_autorisatie returns the WHERE-clause for the current user.
This clause can be different for different users. This can be handy for batch-processing.

FUNCTION SBR$AUTORISATIE.RLS_AUTORISATIE
(p_obj_schema VARCHAR2
,p_obj_name VARCHAR2)
RETURN VARCHAR2
IS
t_predicate VARCHAR2(4000) := ’1=1′;
BEGIN
IF t_rls_aut_tab.exists (p_obj_name)
THEN
t_predicate := t_rls_aut_tab(p_obj_name);
END IF;
RETURN (t_predicate);
END RLS_AUTORISATIE;

By using the extra context-data, I don’t need the USER_column in my tables.
Users can only access companies they’re authorised for:

SELECT *
FROM COMPANIES
WHERE sbr$autorisatie.autorisatie_company (company_code) = sbr.vtrue;

FUNCTION autorisatie_company
(p_company_code VARCHAR2)
RETURN VARCHAR2
IS
t_return sbr.tp_chr%TYPE := sbr.vfalse;
BEGIN
IF t_aut_company_tab.exists (p_company_code)
THEN
t_return := sbr.vtrue;
END IF;
RETURN (t_return);
END autorisatie_company;

For the Batch-usser, the where-clause from the function SBR$AUTORISATIE.RLS_AUTORISATIE results in:

SELECT *
FROM COMPANIES
WHERE 1=1;

Other tables can depend on this authorised comany table:

SELECT*
FROM COMPANY_LOCATIONS CLS
WHERE EXISTS (SELECT 1 FROM COMPANIES CPS WHERE CPS.COMPANY_CODE = CLS.COMPANY_CODE)

And for batch-users the where_clause can be:

SELECT*
FROM COMPANY_LOCATIONS CLS
WHERE 1=1

I saw a great article on the Amis blog a few days ago and made a note to have a look and talk about it here. The article is written by Lucas Jellema and is titled ” Standard for Database….[Read More]

I saw a great article on the Amis blog a few days ago and made a note to have a look and talk about it here. The article is written by Lucas Jellema and is titled “Standard for Database Development – Getting rid of USER from PL/SQL and SQL – no longer is USER equivalent to End User”. This is a great article that talks about the need to get rid of the USER pseudo function from older code written in the days when all database users had their own database account and using the function did return the correct user. This was in the days before proxy users and connection pooling. Lucas starts with the reasons USER was used and the implications of using it now and why it should be removed and the fact that he is saying it shouldn’t be removed in all cases. Lucas goes on to show some examples of a home grown application user table and also a VPD example. He goes on to give examples of how the user might be set and the issues of application servers, middle tiers and logon triggers. Lucas also talks about the fact that the use of USER translates to a select from dual and how this has improved in 10g.

Great paper and well worth a read.