More About Profiles

SQLJ profiles contain information about your embedded SQL operations, with a separate profile being created for each connection context class (or, equivalently, for each type of database schema) that your application uses. Profiles are created during the SQLJ translator's code generation phase and customized during the customization phase. Customization enables your application to use vendor-specific database features. Separating these vendor-specific operations into your profiles enables the rest of your generated code to remain generic.

Each profile contains a series of entries for the SQLJ statements that use the relevant connection context class, where each entry corresponds to one SQL operation in your application.

Profiles exist as serialized objects stored in resource files packaged with your application. Because of this, profiles can be loaded, read, and modified (added to or re-customized) at any time. When profiles are customized, information is only added, never removed. Multiple customizations can be made without losing preceding customizations, so that your application maintains the capability to run in multiple environments. This is known as binary portability.

For profiles to have binary portability, SQLJ industry-standard requirements have been met in the Oracle SQLJ implementation.

Creation of a Profile During Code Generation

During code generation, the translator creates each profile as follows:

1. Creates a profile object as an instance of the sqlj.runtime.profile.Profile class.

2. Inserts information about your embedded SQL operations (for SQLJ statements that use the relevant connection context class) into the profile object.

3. Serializes the profile object into a Java resource file, referred to as a profile file, with a .ser file name extension.

As discussed in "Code Generation", profile file names for application Foo are of the form:

Foo_SJProfilen.ser

SQLJ generates Foo_SJProfile0.ser, Foo_SJProfile1.ser, and so on as needed (depending on how many connection context classes are used). Or, if the -ser2class option is enabled, then SQLJ generates Foo_SJProfile0.class, Foo_SJProfile1.class, and so on.

Each profile has a getConnectedProfile() method that is called during SQLJ runtime. This method returns something equivalent to a JDBC Connection object but with added functionality. This is further discussed in "Functionality of a Customized Profile at Runtime".

Sample Profile Entry

Below is a sample SQLJ executable statement with the profile entry that would result. For simplicity, the profile entry is presented as plain text with irrelevant portions omitted.

Note that in the profile entry, the host variable is replaced by JDBC syntax (the question mark).

SQLJ Executable Statement

Presume the following declaration:

#sql iterator Iter (double sal, String ename);

And presume the following executable statements:

String ename = 'Smith';
Iter it;
...
#sql it = { select ENAME, SAL from EMP where ENAME = :ename };

Corresponding SQLJ Profile Entry

=================================================================
...
#sql { select ENAME, SAL from EMP where ENAME = ? };
...
PREPARED_STATEMENT executed via EXECUTE_QUERY 
role is QUERY
descriptor is null
contains one parameters
1. mode: IN, java type: java.lang.String (java.lang.String),
   sql type: VARCHAR, name: ename, ...
result set type is NAMED_RESULT
result set name is Iter
contains 2 result columns
1. mode: OUT, java type: double (double),
   sql type: DOUBLE, name: sal, ...
2. mode: OUT, java type: java.lang.String (java.lang.String),
   sql type: VARCHAR, name: ename, ...
=================================================================

---