Object Type Inheritance Design Time: Artifact Generation

9-98 Oracle Fusion Middleware Users Guide for Technology Adapters

9.7.3.9 Referencing Types in Other Schemas

You can refer to types defined in other schemas if the necessary privileges to access them have been granted. For example, suppose type OBJ was declared in SCHEMA1: SQL CREATE TYPE OBJ AS OBJECT …; The type of a parameter in a stored procedure declared in SCHEMA2 can be type OBJ from SCHEMA1: CREATE PROCEDURE PROC O IN SCHEMA1.OBJ AS BEGIN … END; This is possible only if SCHEMA1 granted permission to SCHEMA2 to access type OBJ: SQL GRANT EXECUTE ON OBJ TO SCHEMA2; If the required privileges are not granted, an error occurs when trying to create procedure PROC in SCHEMA2: PLS-00201: identifier SCHEMA1.OBJ must be declared Because the privileges have not been granted, type OBJ from SCHEMA1 is not visible to SCHEMA2; therefore, SCHEMA2 cannot refer to it in the declaration of parameter O.

9.7.3.10 XSD Pruning Optimization

Some user-defined object types can have a very large number of attributes. These attributes can also be defined in terms of other object types that also have many attributes. In short, one object type can become quite large depending on the depth and complexity of its definition. Depending on the situation, many attributes of a large object type may not even be necessary. It is therefore sometimes desirable to omit these attributes from the objects schema definition altogether. This can be done by physically removing the unwanted XSD elements from the definition of the object type. Consider the following example where a stored procedure has a parameter whose type is a complex user-defined type: SQL CREATE TYPE OBJ AS OBJECT A, NUMBER, B SqlType, C SqlType, ...; SQL CREATE PROCEDURE PROC O OBJ AS BEGIN ... END; The InputParameters root element contains a single element for the parameter, O from the APIs signature. A complexType definition is to be added to the generated XSD for the object type, as shown in the following code snippet: complexType name=OBJ sequence element name=A type=decimal db:type=NUMBER minOccurs=0 nillable=true element name=B ... element name=C ... ... sequence complexType If attributes B and C are not required, then their element in the complexType definition of OBJ can be removed regardless of its type. Values are not required for these attributes in the instance XML. If parameter O had been an output parameter, then elements corresponding with the pruned attributes are also omitted in the generated XML. Oracle JCA Adapter for Database 9-99 Suppose that the type of parameter A was also a user-defined object type and that the definition of OBJ changed accordingly, as shown in the following example: SQL CREATE TYPE FOO AS OBJECT X NUMBER, Y NUMBER, Z NUMBER; SQL CREATE TYPE OBJ AS OBJECT A FOO, B SqlType, C SqlType, ...; In such a case, the API remains unchanged. Elements corresponding to unwanted attributes in the definition of FOO can also be removed regardless of their type. So, for example, if Y is not required, then its element in the complexType definition of FOO can be removed in the XSD file. Pruning the XSD file in this fashion improves the run-time performance of the adapter and can significantly reduce memory consumption, as well.

9.7.4 Run Time: Before Stored Procedure Invocation

This section discusses important considerations of stored procedure support and a brief overview of some important details regarding what happens before the invocation of a stored procedure or function. This section includes the following topics: ■ Section 9.7.4.1, Value Binding ■ Section 9.7.4.2, Data Type Conversions

9.7.4.1 Value Binding

Consider the extraction of values from the XML file and how the run time works given those values. The possible cases for data in the XML file corresponding to the value of a parameter whose type is one of the supported primitive data types are as follows: 1. The value of an element is specified for example, X100X, here X=100. 2. The value of an element is not specified for example, X, here X=null. 3. The value is explicitly specified as null for example, X xsi:nil=true, here X=null. 4. The element is not specified in the XML file at all for example, X = default value. In the first case, the value is taken from the XML file as is and is converted to the appropriate object according to its type. That object is then bound to its corresponding parameter during preparation of the stored procedure invocation. Note: Only attributes in user-defined object types can be pruned. You cannot prune remove a parameter of the stored procedure by removing its element from the InputParameters root element. This can result in an error at run time unless the parameter has a default clause. Note: There is one notable difference that distinguishes Microsoft SQL Server from IBM DB2, MySQL, and AS400. SQL Server supports parameters that can include a default value in the definition of a stored procedure. Because IBM DB2, MySQL, and AS400 do not support parameter defaults, every parameter must be represented as an element in the instance XML.