When you want to make a distinction between different databases (like Development, Test, Acceptance, and Production) and have a single code base, conditional compilation can help out. Most of the time I read about conditional compilation when the use case is to eliminate code from the production environment, like instrumentation, which is of course a legit scenario. Some functionality should never run on Production, but likewise some functionality should never run on Dev, Test or Acceptance.
For example; we sent out emails to customers about their order statusses. This functionality should only be run on the Production database, and never-ever on any of the other databases. Initially there was a toggle in the application dictating if the emails should go to customers or to a dummy email address within the company. How fool-proof is this solution? Short answer: it's not. Sooner or later there will be someone who sets the toggle to "Sent to Customers" in the wrong environment. Of course there are many more examples like this one.
Anyway, to determine the environment which can be used for conditional compilation, I use a package specification which is compiled dynamically. Using the database name, which can be found in the USERENV context, the value is determined. To output a textual representation of a boolean value, I use LOGGER.TOCHAR to output "true", "false" or "null", but of course you can also write your own boolean-to-text-translation.
declare l_pack_spec varchar2(32767); l_env varchar2(25); begin l_env := sys_context ('userenv', 'db_name'); l_pack_spec := 'create or replace package environment_pkg'||chr(10); l_pack_spec := l_pack_spec ||'is'||chr(10); l_pack_spec := l_pack_spec ||' --=='||chr(10); l_pack_spec := l_pack_spec ||' -- Environment Information, useful for conditional compilation'||chr(10); l_pack_spec := l_pack_spec ||' development constant boolean := '||lower (logger.tochar (l_env = 'DEV'))||';'||chr(10); l_pack_spec := l_pack_spec ||' test constant boolean := '||lower (logger.tochar (l_env = 'TST'))||';'||chr(10); l_pack_spec := l_pack_spec ||' acceptance constant boolean := '||lower (logger.tochar (l_env = 'ACC'))||';'||chr(10); l_pack_spec := l_pack_spec ||' production constant boolean := '||lower (logger.tochar (l_env = 'PRD'))||';'||chr(10); l_pack_spec := l_pack_spec ||' --=='||chr(10); l_pack_spec := l_pack_spec ||'end environment_pkg;'||chr(10); execute immediate l_pack_spec; end;
When you run the code above, the resulting code will be something like:
package environment_pkg is --== -- Environment Information, useful for conditional compilation development constant boolean := true; test constant boolean := false; acceptance constant boolean := false; production constant boolean := false; --== end environment_pkg;
Indicating that the current database is the Development database.
Now you can use conditional compilation to include or exclude certain code sections, like:
$if environment_pkg.production $then -- Here comes the code to send an email to customers .... $else -- Here comes the code to send an email to a dummy internal address .... $end
To see the effect of conditional compilation, what does the code actually look like, you can use the built in package DBMS_PREPROCESSOR.PRINT_POST_PROCESSED_SOURCE which output the result to DBMS_OUTPUT
set serveroutput on begin dbms_preprocessor.print_post_processed_source (object_type => 'PACKAGE BODY' ,schema_name => user ,object_name => 'MAIL_PKG' -- package where you use the conditional compilation ); end; /