8 Object Type Translator Utility

Specifying OTT Parameters

You can specify OTT parameters either on the command line or in a configuration file. Certain parameters can also be specified in the INTYPE file.

If you specify a parameter in more than one place, then its value on the command line takes precedence over its value in the INTYPE file. The value in the INTYPE file takes precedence over its value in a user-defined configuration file, which takes precedence over its value in the default configuration file.

Parameter precedence then is as follows:

1. OTT command line

2. Value in INTYPE file

3. User-defined configuration file

4. Default configuration file

For global options (that is, options on the command line or options at the beginning of the INTYPE file before any TYPE statements), the value on the command line overrides the value in the INTYPE file. (The options that can be specified globally in the INTYPE file are CASE, INITFILE, INITFUNC, MAPFILE and MAPFUNC, but not HFILE or CPPFILE.) Anything in the INTYPE file in a TYPE specification applies to a particular type only and overrides anything on the command line that would otherwise apply to the type. So if you enter TYPE person HFILE=p.h, then it applies to person only and overrides the HFILE on the command line. The statement is not considered a command line parameter.

Invoking the OTT Utility on the Command Line

On most platforms, the OTT utility is invoked on the command line. You can specify the input and output files and the database connection information at the command line, among other things.

ott userid=hr intype=demoin.typ outtype=demoout.typ code=cpp
   hfile=demo.h cppfile=demo.cpp mapfile=RegisterMappings.cpp

An OTT command line statement consists of the command OTT, followed by a list of OTT utility parameters.

The HFILE parameter is almost always used. If omitted, then HFILE must be specified individually for each type in the INTYPE file. If the OTT utility determines that a type not listed in the INTYPE file must be translated, then an error will be reported. Therefore, it is safe to omit the HFILE parameter only if the INTYPE file was previously generated as an OTT OUTTYPE file.

If the INTYPE file is omitted, then the entire schema will be translated. See the parameter descriptions in the following section for more information.

OTT Utility Parameters

To generate C++ using the OTT utility, the CODE parameter must be set to CODE=CPP. Once CODE=CPP is specified, you are required to specify the CPPFILE and MAPFILE parameters to define the filenames for the method implementation file and the mappings registration function file. The name of the mapping function is derived by the OTT utility from the MAPFILE or you may specify the name with the MAPFUNC parameter. ATTRACCESS is also an optional parameter that can be specified to change the generated code. These parameters control the generation of C++ classes.

• Enter parameters on the OTT command line where parameter is the literal parameter string and value is a valid parameter setting. The literal parameter string is not case sensitive:

  parameter=value
  

• Separate command line parameters by using either spaces or tabs.

• Parameters can also appear within a configuration file, but, in that case, no whitespace is permitted within a line, and each parameter must appear on a separate line. Additionally, the parameters CASE, CPPFILE, HFILE, INITFILE, INTFUNC, MAPFILE, and MAPFUNC can appear in the INTYPE file.

Table 8-1 lists all OTT Utility parameters:

TYPE Person
TYPE joe.Dept
TYPE sam.Company

CREATE TYPE Address AS OBJECT
(
   street    VARCHAR2(40),
   city      VARCHAR(30),
   state     CHAR(2),
   zip_code  CHAR(10)
);

CREATE TYPE Person AS OBJECT
(
   name      CHAR(20),
   age       NUMBER,
   addr      ADDRESS
);

create type CitiesList as varray(100) of varchar2(100);
 
create type Country as object
(  CNo Number(10),
   CName Varchar2(100),
   CNationalName NVarchar2(100),
   MainCities CitiesList);

class Country : public oracle::occi::PObject
{
   private:
      oracle::occi::Number CNO;
      oracle::occi::UString CNAME;
      oracle::occi::UString CNATIONALNAME;
      OCCI_STD_NAMESPACE:::vector< oracle::occi::UString > MAINCITIES;

   public:

      oracle::occi::Number getCno() const;
      void setCno(const oracle::occi::Number &value);

      oracle::occi::UString getCname() const;
      void setCname(const oracle::occi::UString &value);
 
      oracle::occi::UString getCnationalname() const;
      void setCnationalname(const oracle::occi::UString &value);
 
      OCCI_STD_NAMESPACE::vector< oracle::occi::UString >& getMaincities();
      const OCCI_STD_NAMESPACE::vector< oracle::occi::UString >& 
          getMaincities() const;
     void setMaincities(const OCCI_STD_NAMESPACE::vector< oracle::occi::UString
          > &value);
...
}

class Country : public oracle::occi::PObject
{
   private:
      oracle::occi::Number CNO;
      oracle::occi::string CNAME;
      oracle::occi::UString CNATIONALNAME;
      OCCI_STD_NAMESPACE::vector< std::string > MAINCITIES;

   public:

      oracle::occi::Number getCno() const;
      void setCno(const oracle::occi::Number &value);

      oracle::occi::string getCname() const;
      void setCname(const OCCI_STD_NAMESPACE::string &value);
 
      oracle::occi::UString getCnationalname() const;
      void setCnationalname(const oracle::occi::UString &value);
 
      OCCI_STD_NAMESPACE::vector< OCCI_STD_NAMESPACE::string>& 
         getMaincities();
      const OCCI_STD_NAMESPACE::vector< OCCI_STD_NAMESPACE::string >&
         getMaincities() const;
     void setMaincities(const OCCI_STD_NAMESPACE::vector
         < OCCI_STD_NAMESPACE::string > &value);
...
}

USERID=username[@db_name]

OTT username ...

Where OTT Parameters Can Appear

Supply OTT parameters on the command line, in a CONFIG file named on the command line, or both. Some parameters are also allowed in the INTYPE file.

The OTT utility is invoked as follows:

OTT parameters

You can name a configuration file on the command line with the CONFIG parameter as follows:

CONFIG=filename

If you name this parameter on the command line, then additional parameters are read from the configuration file named filename.

In addition, parameters are also read from a default configuration file that resides in an operating system-dependent location. This file must exist, but can be empty. If you choose to enter data in the configuration file, note that no white space is allowed on a line and parameters must be entered one to a line.

If the OTT utility is executed without any arguments, then an online parameter reference is displayed.

The types for the OTT utility to translate are named in the file specified by the INTYPE parameter. The parameters CASE, CPPFILE, HFILE, INITFILE, INITFUNC, MAPFILE, and MAPFNC may also appear in the INTYPE file. OUTTYPE files generated by the OTT utility include the CASE parameter, and include the INITFILE, and INITFUNC parameters if an initialization file was generated or the MAPFILE and MAPFUNC parameters if C++ codes was generated. The OUTTYPE file, as well as the CPPFILE for C++, specifies the HFILE individually for each type.

The case of the OTT command is operating system-dependent.

File Name Comparison Restriction

Currently, the OTT utility determines if two files are the same by comparing the filenames provided by the user either on the command line or in the INTYPE file. But one potential problem can occur when the OTT utility needs to know if two filenames refer to the same file. For example, if the OTT-generated file foo.h requires a type declaration written to foo1.h, and another type declaration written to /private/smith/foo1.h, then the OTT utility should generate one #include if the two files are the same, and two #includes if the files are different. In practice, though, it concludes that the two files are different, and generates two #includes as follows:

#ifndef FOO1_ORACLE
#include "foo1.h"
#endif
#ifndef FOO1_ORACLE
#include "/private/smith/foo1.h"
#endif

If foo1.h and /private/smith/foo1.h are different files, then only the first one will be included. If foo1.h and /private/smith/foo1.h are the same file, then a redundant #include will be written.

Therefore, if a file is mentioned several times on the command line or in the INTYPE file, then each mention of the file should use exactly the same filename.

Overview of the INTYPE File

CASE=LOWER
TYPE employee
   TRANSLATE SALARY$ AS salary
             DEPTNO AS department
TYPE ADDRESS
TYPE item
TYPE "Person"
TYPE PURCHASE_ORDER AS p_o

The OTT utility may need to translate additional types that are not listed in the INTYPE file. This is because the OTT utility analyzes the types in the INTYPE file for type dependencies before performing the translation, and it translates other types as necessary. For example, if the ADDRESS type were not listed in the INTYPE file, but the Person type had an attribute of type ADDRESS, then the OTT utility would still translate ADDRESS because it is required to define the Person type.

A normal case insensitive SQL identifier can be spelled in any combination of uppercase and lowercase in the INTYPE file, and is not quoted.

Use quotation marks, such as TYPE "Person" to reference SQL identifiers that have been created in a case sensitive manner, for example, CREATE TYPE "Person". A SQL identifier is case sensitive if it was quoted when it was declared. Quotation marks can also be used to refer to a SQL identifier that is an OTT-reserved word, for example, TYPE "CASE". In this case, the quoted name must be in uppercase if the SQL identifier was created in a case insensitive manner, for example, CREATE TYPE Case. If an OTT-reserved word is used to refer to the name of a SQL identifier but is not quoted, then the OTT utility will report a syntax error in the INTYPE file.

Structure of the INTYPE File

The INTYPE and OUTTYPE files list the types translated by the OTT utility and provide all the information needed to determine how a type or attribute name is translated to a legal C or C++ identifier. These files contain one or more type specifications, and may also contain specifications of CASE, CPPFILE, HFILE, INITFILE, INITFUNC, MAPFILE, or MAPFUNC.

If the CASE, INITFILE, INITFUNC, MAPFILE, or MAPFUNC options are present, then they must precede any type specifications. If these options appear both on the command line and in the INTYPE file, then the value on the command line is used.

TYPE employee
   TRANSLATE SALARY$ AS salary
      DEPTNO AS department
TYPE ADDRESS
TYPE PURCHASE_ORDER AS p_o

TYPE type_name
[GENERATE type_identifier]
[AS type_identifier]
[VERSION [=] version_string]
[HFILE [=] hfile_name]
[CPPFILE [=] cppfile_name]
[TRANSLATE{member_name [AS identifier]}...]

[schema_name.]type_name

Nested #include File Generation

HFILE files generated by the OTT utility #include other necessary files, and #define a symbol constructed from the name of the file. This symbol #defined can then be used to determine if the related HFILE file has already been #included. Consider, for example, a database with the following types:

create type px1 AS OBJECT (col1 number, col2 integer);
create type px2 AS OBJECT (col1 px1);
create type px3 AS OBJECT (col1 px1);

The INTYPE file contains the following information:

CASE=lower
type pxl
   hfile tott95a.h
type px3
   hfile tott95b.h

You invoke the OTT utility as follows:

>ott hr intype=tott95i.typ outtype=tott95o.typ code=cpp
...
Enter password: password

The OTT utility then generates the following two header files, named tott95a.h and tott95b.h. They are listed in

#ifndef TOTT95A_ORACLE
# define TOTT95A_ORACLE

#ifndef OCCI_ORACLE
# include <occi.h>
#endif

/************************************************************/
//  generated declarations for the PX1 object type.
/************************************************************/

class px1 : public oracle::occi::PObject {

protected:
   oracle::occi::Number col1;
   oracle::occi::Number col2;

public:
   void *operator new(size_t size);
   void *operator new(size_t size, const oracle::occi::Connection * sess,
      const OCCI_STD_NAMESPACE::string& table);
   void *operator new(size_t, void *ctxOCCI_);
   void *operator new(size_t size, const oracle::occi::Connection *sess,
      const OCCI_STD_NAMESPACE::string &tableName, 
      const OCCI_STD_NAMESPACE::string &typeName,
      const OCCI_STD_NAMESPACE::string &tableSchema, 
      const OCCI_STD_NAMESPACE::string &typeSchema);
   void getSQLTypeName(oracle::occi::Environment *env, void **schemaName,
      unsigned int &schemaNameLen, void **typeName,
      unsigned int &typeNameLen) const;
   px1();
   px1(void *ctxOCCI_) : oracle::occi::PObject (ctxOCCI_) { };
   static void *readSQL(void *ctxOCCI_);
   virtual void readSQL(oracle::occi::AnyData& streamOCCI_);
   static void writeSQL(void *objOCCI_, void *ctxOCCI_);
   virtual void writeSQL(oracle::occi::AnyData& streamOCCI_);
   ~px1();
};

#endif

#ifndef TOTT95B_ORACLE
# define TOTT95B_ORACLE

#ifndef OCCI_ORACLE
# include <occi.h>
#endif

#ifndef TOTT95A_ORACLE
# include "tott95a.h"
#endif

/************************************************************/
//  generated declarations for the PX3 object type.
/************************************************************/

class px3 : public oracle::occi::PObject {

protected:
   px1 * col1;

public:
   void *operator new(size_t size);
   void *operator new(size_t size, const oracle::occi::Connection * sess,
      const OCCI_STD_NAMESPACE::string& table);
   void *operator new(size_t, void *ctxOCCI_);
   void *operator new(size_t size, const oracle::occi::Connection *sess,
      const OCCI_STD_NAMESPACE::string &tableName, 
      const OCCI_STD_NAMESPACE::string &typeName,
      const OCCI_STD_NAMESPACE::string &tableSchema, 
      const OCCI_STD_NAMESPACE::string &typeSchema);
   void getSQLTypeName(oracle::occi::Environment *env, void **schemaName,
      unsigned int &schemaNameLen, void **typeName,
      unsigned int &typeNameLen) const;
   px3();
   px3(void *ctxOCCI_) : oracle::occi::PObject (ctxOCCI_) { };
   static void *readSQL(void *ctxOCCI_);
   virtual void readSQL(oracle::occi::AnyData& streamOCCI_);
   static void writeSQL(void *objOCCI_, void *ctxOCCI_);
   virtual void writeSQL(oracle::occi::AnyData& streamOCCI_);
   ~px3();
};
#endif

In the tott95b.h file, the symbol TOTT95B_ORACLE is #define d at the beginning of the file. This enables you to conditionally #include this header file in another file. To accomplish this, you would use the following construct:

#ifndef TOTT95B_ORACLE
#include "tott95b.h"
#endif

By using this technique, you can #include tott95b.h in, say foo.h, without having to know whether some other file #included in foo.h also #includes tott95b.h.

Next, the file tott95a.h is included because it contains the declaration of struct px1, that tott95b.h requires. When the INTYPE file requests that type declarations be written to more than one file, the OTT utility determines which other files each HFILE must #include, and generates each necessary #include.

Note that the OTT utility uses quotes in this #include. When a program including tott95b.h is compiled, the search for tott95a.h begins where the source program was found, and will thereafter follow an implementation-defined search rule. If tott95a.h cannot be found in this way, then a complete filename (for example, a UNIX absolute path name beginning with a slash character (/)) should be used in the INTYPE file to specify the location of tott95a.h.

Default Name Mapping

When the OTT utility creates a C or C++ identifier name for an object type or attribute, it translates the name from the database character set to a legal C or C++ identifier. First, the name is translated from the database character set to the character set used by the OTT utility. Next, if a translation of the resulting name is supplied in the INTYPE file, that translation is used. Otherwise, the OTT utility translates the name character-by-character to the compiler character set, applying the character case specified in the CASE parameter. The following text describes this in more detail.

When the OTT utility reads the name of a database entity, the name is automatically translated from the database character set to the character set used by the OTT utility. In order for the OTT utility to read the name of the database entity successfully, all the characters of the name must be found in the OTT character set, although a character may have different encodings in the two character sets.

The easiest way to guarantee that the character set used by the OTT utility contains all the necessary characters is to make it the same as the database character set. Note, however, that the OTT character set must be a superset of the compiler character set. That is, if the compiler character set is 7-bit ASCII, then the OTT character set must include 7-bit ASCII as a subset, and if the compiler character set is 7-bit EBCDIC, then the OTT character set must include 7-bit EBCDIC as a subset. The user specifies the character set that the OTT utility uses by setting the NLS_LANG environment variable, or by some other operating system-specific mechanism.

Once the OTT utility has read the name of a database entity, it translates the name from the character set used by the OTT utility to the compiler's character set. If a translation of the name appears in the INTYPE file, then the OTT utility uses that translation.

Otherwise, the OTT utility attempts to translate the name as follows:

1. If the OTT character set is a multibyte character set, all multibyte characters in the name that have single-byte equivalents are converted to those single-byte equivalents.

2. The name is converted from the OTT character set to the compiler character set. The compiler character set is a single-byte character set such as US7ASCII.

3. The case of letters is set according to how the CASE parameter is defined, and any character that is not legal in a C or C++ identifier, or that has no translation in the compiler character set, is replaced by an underscore character (_). If at least one character is replaced by an underscore, then the OTT utility gives a warning message. If all the characters in a name are replaced by underscores, the OTT utility gives an error message.

Character-by-character name translation does not alter underscores, digits, or single-byte letters that appear in the compiler character set, so legal C or C++ identifiers are not altered.

Name translation may, for example, translate accented single-byte characters such as o with an umlaut or an a with an accent grave to o or a, with no accent, and may translate a multibyte letter to its single-byte equivalent. Name translation will typically fail if the name contains multibyte characters that lack single-byte equivalents. In this case, the user must specify name translations in the INTYPE file.

The OTT utility will not detect a naming clash caused by two or more database identifiers being mapped to the same C name, nor will it detect a naming problem where a database identifier is mapped to a C keyword.

C++ Classes Generated by the OTT Utility

When the OTT utility generates a C++ class from a database object type, the class declaration contains one element corresponding to each attribute of the object type. The datatypes of the attribute are mapped to types that are used in Oracle object datatypes, as defined in Table 8-2.

For each class, two new operators, readSQL() and writeSQL() methods are generated. They are used by OCCI to marshall and unmarshall objects.

By default, the C++ classes generated by the OTT utility for an object type are derived from the PObject class, so the generated constructor in the class also derives from the PObject class. For inherited database types, the class is derived from the parent type class as is the generated constructor and only the elements corresponding to attributes not already in the parent class are included.

Class declarations that include the elements corresponding to the database type attributes and the method declarations are included in the header file generated by the OTT utility. The method implementations are included in the CPPFILE file generated by the OTT utility.

Map Registry Function

One function to register the mappings with the environment is generated by the OTT utility. The function contains the mappings for all the types translated by the invocation of the OTT utility. The function name is either specified in the MAPFUNC parameter or, if that parameter is not specified, derived from MAPFILE parameter. The only argument to the function is the pointer to Environment.

The function uses the provided Environment to get Map and then registers the mapping of each translated type.

Extending C++ Classes

To enhance the functionality of a class generated by the OTT utility, you can derive new classes. You can also add methods to a class, but Oracle does not recommend doing so due to an inherent risk.

Assume that you want to generate the both CAddress and MyAddress classes from the SQL object type ADDRESS. MyAddress class can be derived from CAddress class. To do this, the OTT utility must alter the code it generates:

• By using the MyAddress class instead of the CAddress class to represent attributes whose database type is ADDRESS

• By using the MyAddress class instead of the CAddress class to represent vector and REF elements whose database type is ADDRESS

• By using the MyAddress class instead of the CAddress class as the base class for database object types that are inherited from ADDRESS. Even though a derived class is a subtype of MyAddress, the readSQL() and writeSQL() methods called are those of the CAddress class.

TYPE ADDRESS GENERATE CAdress AS MyAddress

CASE = SAME
MAPFILE = RegisterMappings_5.cpp

TYPE FULL_NAME GENERATE CFullName AS MyFullName
   TRANSLATE first_name as FirstName
             last_name as LastName

TYPE ADDRESS GENERATE CAddress AS MyAddress
TYPE PERSON GENERATE CPerson AS MyPerson
TYPE STUDENT GENERATE CStudent AS MyStudent

Properties of OTT Markers

These items describe the properties of OTT Markers Support:

1. User must use the command line option USE_MARKER=TRUE from the very first time OTT is invoked to generate a file.

2. User should treat markers like other C++ statements; a marker will be defined by OTT in the generated file as follows when the command line option USE_MARKER=TRUE is used:

   #ifndef OTT_USERCODE_START 
            #define OTT_USERCODE_START 
            #endif
            #ifndef OTT_USERCODE_END
            #define OTT_USERCODE_END
            #endif
   

3. The markers, OTT_USERCODE_START and OTT_USERCODE_END, must be preceded and followed by white space.

4. OTT will copy the text/code given within markers verbatim along with the markers while generating the code next time,

   User modified code:

   1  // --- modified generated code 
            2  OTT_USERCODE_START 
            3  // --- including "myfullname.h" 
            4  #ifndef MYFULLNAME_ORACLE 
            5  #include "myfullname.h" 
            6  #endif 
            7  OTT_USERCODE_END 
            8  // --- end of code addition 
   

   Carried forward code:

   1  OTT_USERCODE_START 
            2  // --- including "myfullname.h" 
            3  #ifndef MYFULLNAME_ORACLE 
            4  #include "myfullname.h" 
            5  #endif 
            6  OTT_USERCODE_END 
   

5. OTT will not be able to carry forward user added code properly if the database TYPE or INTYPE file undergoes changes as shown in the following cases:

   • If user modifies the case of the type name, OTT will fail to find out the class name with which the code was associated earlier as the case of the class name got modified by the user in the INTYPE file.

     CASE=UPPER                               CASE=LOWER 
     TYPE employee                            TYPE employee 
     TRANSLATE SALARY$ AS salary              TRANSLATE SALARY$ AS salary 
        DEPTNO AS department                     DEPTNO AS department 
     TYPE ADDRESS                             TYPE ADDRESS 
     TYPE item                                TYPE item 
     TYPE "Person"                            TYPE "Person" 
     TYPE PURCHASE_ORDER AS p_o               TYPE PURCHASE_ORDER AS p_o
     

   • If user asks to generate the class with different name (GENERATE AS clause of INTYPE file), OTT will fail to find out the class name with which the code was associated earlier as the class name got modified by the user in the INTYPE file.

     CASE=LOWER                           CASE=LOWER 
     TYPE employee                        TYPE employee 
     TRANSLATE SALARY$ AS salary          TRANSLATE SALARY$ AS salary 
        DEPTNO AS department                 DEPTNO AS department 
     TYPE ADDRESS                         TYPE ADDRESS 
     TYPE item                            TYPE item 
     TYPE "Person"                        TYPE "Person" 
     TYPE PURCHASE_ORDER AS p_o           TYPE PURCHASE_ORDER AS
                                             purchase_order
     

6. If OTT encounters an error while parsing an .h or .cpp file, it reports the error and leaves the file having error as it is so that the user can go back and correct the error reported, and rerun OTT.

7. OTT will flag an error if:

   • it does not find a matching OTT_USERCODE_END for OTT_USERCODE_START encountered

   • markers are nested (OTT finds next OTT_USERCODE_START before OTT_USERCODE_END is found for the previous OTT_USERCODE_START)

   • OTT_USERCODE_END is encountered before OTT_USERCODE_START

Using OTT Markers

The user must use command line option USE_MARKER=TRUE to turn on marker support. There are two general ways in which OTT markers can carry forward user added code:

1. User code added in .h file.

   • User code added in global scope. This is typically the case when user needs to include different header files, forward declaration, and so on. Refer to the code example provided later.

   • User code added in class declaration. At any point of time OTT generated class declaration will have private scope for data members and public scope for methods, or protected scope for data members and public scope for methods. User blocks can be added after all OTT generated declarations in either access specifiers.

   Example 8-16 How to Add User Code to a Header File Using OTT Utility

   ...                                                 
   #ifndef OTT_USERCODE_START                                  
   #define OTT_USERCODE_START 
   #endif
   #ifndef OTT_USERCODE_END
   #define OTT_USERCODE_END
   #endif           
   
   #ifndef OCCI_ORACLE
   #include <occi.h>
   #endif
   
   OTT_USERCODE_START     // user added code 
   ...
   OTT_USERCODE_END
   
   #ifndef ...            // OTT generated include
   #include " ... "
   #endif
   
   OTT_USERCODE_START     // user added code 
   ...
   OTT_USERCODE_END
   
   class <class_name_1> : public oracle::occi::PObject
   {  protected:
         ...             // OTT generated data members 
         OTT_USERCODE_START    // user added code  for data member / method
         ...                   //    declaration / inline method
         OTT_USERCODE_END
        
      public:
         void *operator new(size_t size);
         ...
         OTT_USERCODE_START   // user added code  for data member / method
         ...                  // declaration / inline method definition
         OTT_USERCODE_END
   };
     
   OTT_USERCODE_START     // user added code 
   ...
   OTT_USERCODE_END
   
   class <class_name_2> : public oracle::occi::PObject
   {
      ...
   };
   
   OTT_USERCODE_START     // user added code 
   ...                                                          
   OTT_USERCODE_END                                             
   ...                                                                  
   #endif                 // end of .h file                     
   

2. User code added in .cpp file. OTT will support adding a new user defined method within OTT markers. The user block must be added at the beginning of the file, just after the includes and before the definition of OTT generated methods. If there are more than one OTT generated includes, user code can also be added between OTT generated includes. User code added in any other part of a xxx.cpp file will not be carried forward.

   Example 8-17 How to Add User Code to the Source File Using the OTT Utility

   #ifndef OTT_USERCODE_START                                   
   #define OTT_USERCODE_START                                  
   #endif                                                       
                                                                      
   #ifndef OTT_USERCODE_END
   #define OTT_USERCODE_END
   #endif
   ...
      OTT_USERCODE_START    // user added code 
         ...
      OTT_USERCODE_END
   ...
      OTT_USERCODE_START    // user added code 
         ...
      OTT_USERCODE_END
   
   /*************************************************************
   / generated method implementations for the ... object type.
   /*************************************************************/
   
   void *<class_name_1>::operator new(size_t size)
   {
      return oracle::occi::PObject::operator new(size);
   }
   ...                                                          
   // end of .cpp file