Now,my suggestion for New Projects:
just create all Constants as Functions and write a Package Body for each Function
and return the respective Values for Constants.

This has the Advantage that it’s Type Safe because i can specify the Return Type in the Function.
The only Disadvantage here is that one has to write too much code but for this we could
write PL-SQL to generate this Package automatically by selecting from a Table where all our
constants are temporarily stored, for instance from table my_constants from Andre.

Oh, one more Disadvantage is that if we have a New Constant then we have to change the Package Spec and Body;
i would have preferred a Solution whereby a Constant Addition would not have necessitated a package Change.

So for example:

create or replace package my_constants
is
–my_name constant varchar2(30) := ‘Andre’;
function my_name return varchar2 ;
function my_salary return number ;
end;
/

create or replace package body my_constants
is

function my_name
return varchar2
is
begin
return ‘Andre’;
end ;

function my_salary
return number
is
begin
return 200000;
end my_salary;
–add more functions for each new constant here
end;
/

select my_constants.MY_NAME from dual
/

What do you think about this Solution?

Regards,

Pasko

It uses the string global g_bidon to return a value. The disadvantage is that the value is always a string. But I suppose that functions could be added to cater for other data types.

PACKAGE myConst IS
–
g_bidon VARCHAR2(32767) := NULL;
–
— lang code
–
c_lang_en CONSTANT languages.language_code%TYPE := ‘EN’;
c_lang_fr CONSTANT languages.language_code%TYPE := ‘FR’;
c_lang_es CONSTANT languages.language_code%TYPE := ‘ES’;
–
— Functions
–
FUNCTION getConstant (p_constant_name IN VARCHAR2 DEFAULT NULL)
RETURN VARCHAR2;
–
END myConst;

PACKAGE BODY myConst IS

FUNCTION getConstant (p_constant_name IN VARCHAR2 DEFAULT NULL)
RETURN VARCHAR2 IS
v_return VARCHAR2(2000);
BEGIN
EXECUTE IMMEDIATE ‘BEGIN myConst.g_bidon := myConst.’||p_constant_name||’; END; ‘;
RETURN g_bidon;
END getConstant;

END myConst;

@Harm
I didn’t write the original code. This function would have never existed if it was up to me.

@Wilfred
We have a webapplication with short living sessions. Memory is not possible for us.

Both old and new solutions have another problem that is not mentioned here. It’s very insecure – anyone having access to this function is able to ruin the whole aplication assuming that owner is able to perform DML or DDLs on objects. Since you have big application – you never know where it exposed and who gets access to the function.

With redesign you have introduced another problem. Though less significant than hard parse – it’s many selects of same row or rows in the same block. You can avoid it with PL/SQL tables that would cache values for the session.

Another disadvantage of both solutions is the package itself – anytime you change the constant you are at risk to make a mistake rendering the package status invalid and the whole application unable to read it. In the newer solution this risk is mitigated because chances are that value is cached into the table but there still can be misses.

After all that I would question if you really need package constants anymore. Isn’t having one single lookup table accessed via single function enough? This would solve all problems. If there contention issues arise than you can consider caching values in PL/SQL table (PL/SQL table is store in PGA for each session so no contention). The only reason to keep package can be that these constants are accessed from PL/SQL blocks much more often than via function now.

Two things we did:
1) make the function DETERMINISTIC. Oracle 10gR2 “caches” the result and only executes the function once for a SQL statement, even if the constant is required in something like a nested loop.
2) The get_constant function first checks in a package variable (PL/SQL table) if the constant is in that table. Initially the table is just empty. If the constant is in the table, return that value. If it’s not in the table, query it using dynamic SQL and store it in the PL/SQL table before returning the value. This bascially implements a PL/SQL caching table in memory.
This way you don’t run the risk of an outdated database “cache” table. The caching is all done in a package (“session”) variable. We found that the get_constant function is only performing the actual dynamic SQL a couple of times for a session since most of the get_constant calls tend to be for the same set of constants.

PS. You can use this PL/SQL caching table trick for all sorts of functions that you expect to be called multiple times with the same parameters.

It would be even better if you can have some sort of memory structure shared by all sessions to do the in-memory caching. This way all sessions benefit from a single session adding something to the cache. I cannot think of a way to do this in PL/SQL. Perhaps something with Java or an external process. (or would that be too much overhead)