Release 3 (8.1.7)
Part Number A83723-01
 Library |
 Product |
 Contents |
 Index |
| Oracle8i SQLJ Developer's Guide and Reference Release 3 (8.1.7) Part Number A83723-01 |
|
This section summarizes the types supported by Oracle SQLJ, including information about new support for JDBC 2.0 types, and backwards compatibility for the 8.0.x and 7.3.x Oracle JDBC drivers.
For a complete list of legal Java mappings for each Oracle SQL type, see the reference information in the Oracle8i JDBC Developer's Guide and Reference.
Table 5-1 lists the Java types that you can use in host expressions when employing the Oracle JDBC drivers. This table also documents the correlation between Java types, SQL types whose typecodes are defined in the class oracle.jdbc.driver.OracleTypes, and datatypes in the Oracle database.
SQL data output to a Java variable is converted to the corresponding Java type. A Java variable input to SQL is converted to the corresponding Oracle datatype.
Where objects, object references, and arrays are referred to as "JPub-generated", this refers to the Oracle JPublisher utility that can be used in defining Java classes to correspond to Oracle8i objects, object references, and arrays. The JPublisher utility is discussed in "JPublisher and the Creation of Custom Java Classes" and documented in further detail in the Oracle8i JPublisher User's Guide.
The following points relate to type support for standard SQLJ features:
java.sql.SQLData to set the public static _SQL_NAME field appropriately. This occurs automatically if you use the Oracle JPublisher utility to generate the class.
Note that this does not follow ISO standard for use of the SQLData interface. In future releases, the Oracle SQLJ implementation will adhere to standard.
char and Character types. Instead, use the Java String type to represent character data.
java.sql.Date type with java.util.Date, which is not directly supported. The java.sql.Date class is a wrapper for java.util.Date that allows JDBC to identify the data as a SQL DATE and adds formatting and parsing operations to support JDBC escape syntax for date values.
NUMBER. Although you can specify additional precision when you declare a NUMBER during table creation (you can declare the total number of places and the number of places to the right of the decimal point), this precision may be lost when retrieving the data through the Oracle JDBC drivers, depending on the Java type that you use to receive the data. (An oracle.sql.NUMBER instance would preserve full information.)
Integer and Float) are useful in cases where null values may be returned by the SQL statement. Primitive types (such as int and float) cannot contain null values. See "Null-Handling" for more information.
The following points relate to Oracle extensions, which are covered in "Oracle Type Extensions" and in Chapter 6, "Objects and Collections":
oracle.sql.CustomDatum to set the public static _SQL_TYPECODE parameter according to values defined in the OracleTypes class. In some cases an additional parameter must be set as well (such as _SQL_NAME for objects and _SQL_BASETYPE for object references). This occurs automatically if you use the Oracle JPublisher utility to generate the class.
See "Oracle Requirements for Classes Implementing CustomDatum".
oracle.sql classes are wrappers for SQL data for each of the Oracle datatypes. The ARRAY, STRUCT, REF, BLOB, and CLOB classes correspond to standard JDBC 2.0 interfaces. For background information about these classes and Oracle extensions, see the Oracle8i JDBC Developer's Guide and Reference.
CustomDatum or SQLData), references (implementing CustomDatum only), collections (implementing CustomDatum only), or other SQL types (for customized handling, implementing CustomDatum only). See "Custom Java Classes".
You can use the Oracle JPublisher utility to automatically generate custom Java classes. See "JPublisher and the Creation of Custom Java Classes".
As indicated in Table 5-1 above, Oracle JDBC and SQLJ support JDBC 2.0 types in the standard java.sql package.
This section lists JDBC 2.0 supported types and discusses Oracle SQLJ requirements for use of these types.
Table 5-2 lists the JDBC 2.0 types supported by Oracle SQLJ. You can use them wherever you can use the corresponding Oracle extensions, summarized in the table.
The Oracle extensions have been available in prior releases and are still available as well. These oracle.sql.* classes provide functionality to wrap raw SQL data, and are described in the Oracle8i JDBC Developer's Guide and Reference.
For more information about support for the types in Table 5-2, see "Support for BLOB, CLOB, and BFILE" and "Support for Weakly Typed Objects, References, and Collections".
The following JDBC 2.0 types are currently not supported in Oracle JDBC or SQLJ:
JAVA_OBJECT--Represents an instance of a Java type in a SQL column.
DISTINCT--A distinct SQL type represented in or retrievable from a basic SQL type (for example, SHOESIZE --> NUMBER).
As with the corresponding Oracle extended types, you can use the standard JDBC 2.0 types in the Oracle SQLJ runtime only if you customize your application with the Oracle customizer, which happens by default when you run the SQLJ translator.
This support requirement is not in full compliance with the forthcoming ISO standard. However, if you use the standard java.sql types in your application, then the source code will be portable. To use it in an alternative SQLJ runtime environment, you would have to re-translate it with an appropriate SQLJ translator.
Oracle JDBC drivers do not support calling arguments or return values of the PL/SQL types TABLE (now known as indexed-by tables), RECORD, or BOOLEAN.
As a workaround, you can create wrapper procedures that process the data as types supported by JDBC. For example, to wrap a stored procedure that uses PL/SQL booleans, you can create a stored procedure that takes a character or number from JDBC and passes it to the original procedure as BOOLEAN, or, for an output parameter, accepts a BOOLEAN argument from the original procedure and passes it as a CHAR or NUMBER to JDBC. Similarly, to wrap a stored procedure that uses PL/SQL records, you can create a stored procedure that handles a record in its individual components (such as CHAR and NUMBER). To wrap a stored procedure that uses PL/SQL tables, you can break the data into components or perhaps use Oracle collection types.
Here is an example of a PL/SQL wrapper procedure MY_PROC for a stored procedure PROC that takes a BOOLEAN as input:
PROCEDURE MY_PROC (n NUMBER) IS BEGIN IF n=0 THEN proc(false); ELSE proc(true); END IF; END; PROCEDURE PROC (b BOOLEAN) IS BEGIN ... END;
Some of the Oracle type extensions supported by the Oracle8i JDBC drivers are either not supported or supported differently by the Oracle 8.0.x and 7.3.x JDBC drivers. Following are the key points:
oracle.sql package, meaning there are no wrapper types such as oracle.sql.NUMBER and oracle.sql.CHAR that you can use to wrap raw SQL data.
ROWID datatype with the OracleRowid class in the oracle.jdbc.driver package.
BLOB, CLOB, and BFILE datatypes with the OracleBlob, OracleClob, and OracleBfile classes in the oracle.jdbc.driver package. These classes do not include LOB and BFILE manipulation methods such as those discussed in "Support for BLOB, CLOB, and BFILE". You must, instead, use the PL/SQL DBMS_LOB package, which is discussed in the same section.
BLOB, CLOB, and BFILE.
Table 5-3 summarizes these differences.
|
 Copyright © 1996-2000, Oracle Corporation. All Rights Reserved. |
|