User-Defined Types Design Time: Artifact Generation

9-96 Oracle Fusion Middleware Users Guide for Technology Adapters vary and ntbl type definitions were defined at the root level, outside of the package, then choosing the test procedure works without issue. The supported way to use collection types Varray and nested table is shown in the following example: SQL create type vary as varray10 of number; SQL create type ntbl as table of varchar210; SQL create package pkg as procedure testv in vary, n in ntbl; end; An OBJECT definition is also generated as a complexType. Its sequence holds one element for each attribute in the OBJECT. The following OBJECT, SQL CREATE TYPE FOO AS OBJECT X VARCHAR2 10, Y NUMBER; is represented as a complexType definition called FOO with two sequence elements. complexType name=FOO sequence element name=X db:type=VARCHAR2 minOccurs=0 nillable=true simpleType restriction base=string maxLength value=10 restriction simpleType element name=Y type=decimal db:type=NUMBER minOccurs=0 nillable=true sequence complexType The minOccurs value is 0 to allow for the element to be removed from the XML file. This causes the value of the corresponding attribute in the OBJECT to be set to null at run time. The nillable value is true to allow empty elements to appear in the XML file, annotated with the xsi:nil attribute, to indicate that the value of the element is null. Again, the db:index attribute is not used. Note the use of a restriction on the VARCHAR2 attribute. The length is known from the declaration of the attribute in the OBJECT.

9.7.3.6 Complex User-Defined Types

User-defined types can be defined in arbitrarily complex ways. An OBJECT can contain attributes whose types are defined as any of the user-defined types mentioned in the preceding section. This means that the type of an attribute in an OBJECT can be another OBJECT, VARRAY, or a nested table, and so on. The base type of a VARRAY or a nested table can also be an OBJECT. Allowing the base type of a collection to be another collection supports multidimensional collections.

9.7.3.7 Object Type Inheritance

The Adapter Configuration Wizard is capable of generating a valid XSD for parameters whose types are defined using OBJECT-type inheritance. Given the following type hierarchy, SQL CREATE TYPE A AS OBJECT A1 NUMBER, A2 VARCHAR2 10 NOT FINAL; SQL CREATE TYPE B UNDER A B1 VARCHAR2 10; and a procedure containing a parameter, X, whose type is B, Oracle JCA Adapter for Database 9-97 SQL CREATE PROCEDURE P X IN B AS BEGIN … END; the Adapter Configuration Wizard generates an InputParameters element for parameter X as element name=X type=db:B db:index=1 db:type=Struct minOccurs=0 nillable=true where the definition of OBJECT type B in the XSD file is generated as the following complexType. complexType name=B sequence element name=A1 type=decimal db:type=NUMBER minOccurs=0 nillable=true element name=A2 db:type=VARCHAR2 minOccurs=0 nillable=true ... element element name=B1 db:type=VARCHAR2 minOccurs=0 nillable=true ... element sequence complexType Restrictions on the maximum length of attributes A2 and B1 are added appropriately. Notice how the OBJECT type hierarchy is flattened into a single sequence of elements that corresponds to all of the attributes in the entire hierarchy.

9.7.3.8 Object References

The Adapter Configuration Wizard can also generate a valid XSD for parameters that are references to OBJECT types for example, object references or are user-defined types that contain an object reference somewhere in their definition. In this example, SQL CREATE TYPE FOO AS OBJECT …; SQL CREATE TYPE BAR AS OBJECT F REF FOO, …; SQL CREATE PROCEDURE PROC X OUT BAR, Y OUT REF FOO AS BEGIN … END; the Adapter Configuration Wizard generates complexType definitions for FOO and BAR as already indicated, except that for BAR, the element for the attribute, F, is generated as element name=F type=db:FOO db:type=Ref minOccurs=0 nillable=true where together, the type and db:type attribute values indicate that F is a reference to the OBJECT type FOO. For a procedure PROC, the following elements are generated in the OutputParameters root element of the XSD file: element name=X type=db:BAR db:index=1 db:type=Struct minOccurs=0 nillable=true element name=Y type=db:FOO db:index=2 db:type=Ref minOccurs=0 nillable=true For Y, note the value of the db:type attribute, Ref. Together with the type attribute, the element definition indicates that Y is a reference to FOO. Note that there is a restriction on the use of object references that limits their parameter mode to OUT only. Passing an IN or INOUT parameter into an API that is either directly a REF or, if the type of the parameter is user-defined, contains a REF somewhere in the definition of that type, is not permitted. 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.