Oracle8i SQLJ Developer's Guide and Reference Release 8.1.5 A64684-01 |
|
Oracle offers flexibility in how users can customize the mapping of Oracle object types, reference types, and collection types to Java classes in a strongly typed paradigm. Developers have the following choices in creating these custom Java classes:
Although you have the option of manually coding your custom Java classes, using JPublisher is advisable. If you need special functionality, you can subclass a class that JPublisher generates or use it as a field in a class that you create.
This manual provides only a minimal level of information and detail regarding the JPublisher utility. See the Oracle8i JPublisher User's Guide for more information.
When you run JPublisher for a user-defined object type, it automatically creates the following:
This class includes getter and setter methods for each attribute. The method names are of the form getFoo()
and setFoo()
for attribute foo
.
Also, you can optionally instruct JPublisher to generate wrapper methods in your class that invoke the associated Oracle object methods executing in the server. This is specified by the -methods=true
option, described later in this section.
This class includes a getValue()
method that returns an instance of your custom object class, and a setValue()
method that updates an object value in the database, taking as input an instance of the custom object class.
This is necessary so that attributes can be materialized in Java whenever an instance of the top-level class is materialized.
When you run JPublisher for a user-defined collection type, it automatically creates the following:
This class includes overloaded getArray()
and setArray()
methods to retrieve or update a collection as a whole, a getElement()
method and setElement()
method to retrieve or update individual elements of a collection, and additional utility methods.
This is necessary so that object elements can be materialized in Java whenever an instance of the collection is materialized.
JPublisher-generated custom Java classes in any of these categories implement the CustomDatum
interface, the CustomDatumFactory
interface, and the getFactory()
method.
This section discusses key JPublisher command-line functionality for specifying the user-defined types that you want to map to Java, and for specifying object class names, collection class names, attribute type mappings, and method wrappers. These key points can be summarized as follows:
-sql
, -user
, and -case
options).
-mapping
option).
-methods
option).
In using JPublisher to create custom Java classes, use the -sql
option to specify the user-defined SQL types that you want to map to Java. You can either specify the custom object class names and custom collection class names or you can accept the defaults.
The default names of your top-level custom classes--the classes that will correspond to the user-defined type names you specify to the -sql
option--are the same as the user-defined type names as you type them. Because SQL names in the database are case-insensitive, you can capitalize them to ensure that your class names are capitalized per convention. For example, if you want to generate a custom class for employee
objects, you can run JPublisher as follows:
% jpub -sql=Employee ...
The default names of lower-level classes, such as for home_address
objects that are attributes of employee
objects, are determined by the JPublisher -case
option. If you do not set the -case
option, it is set to mixed
. This means that the default for the custom class name is to capitalize the initial character of the corresponding user-defined type name, and the initial character of every word unit thereafter. JPublisher interprets underscores (_), dollar signs ($), and any characters that are illegal in Java identifiers as word-unit separators; these characters are discarded in the process.
For example, for Oracle object type home_address
, JPublisher would create class HomeAddress
in source file HomeAddress.java
.
On the JPublisher command line, use the following syntax for the -sql
option (you can specify multiple actions in a single option setting). Use the -user
option to specify the database schema.
-sql=udt1<:mapclass1><,udt2<:mapclass2>>,...,<udtN<:mapclassN>>
Following is an example:
% jpub -sql=Myobj,mycoll:MyCollClass -user=scott/tiger
(There can be no space before or after the comma.)
For the Oracle object myobj
, this command will name it as you typed it, creating source Myobj.java
to define class Myobj
. For the Oracle collection mycoll
, this command will create source MyCollClass.java
to define class MyCollClass
.
You can optionally specify schema names as well--for example, the scott
schema:
% jpub -sql=scott.Myobj,scott.mycoll:MyCollClass -user=scott/tiger
You cannot specify custom reference class names; JPublisher automatically derives them by adding Ref
to custom object class names. For example, if JPublisher produces Java source Myobj.java
to define custom object class Myobj
, then it will also produce Java source MyobjRef.java
to define custom reference class MyobjRef
.
Note:
When specifying the schema, such as |
To create custom Java classes for the object and collection types defined in "User-Defined Types in the Database", you can run JPublisher as follows:
%jpub -user=scott/tiger -sql=Address,Person,Phone_array,Participant_t, Module_t,Moduletbl_t
Or, to explicitly specify the custom object class and custom collection class names:
%jpub -user=scott/tiger -sql=Address,Person,phone_array:PhoneArray, participant_t:ParticipantT,module_t:ModuleT,moduletbl_t:ModuletblT
The second example will produce Java source files Address.java
, AddressRef.java
, Person.java
, PersonRef.java
, PhoneArray.java
, ParticipantT.java
, ParticipantTRef.java
, ModuleT.java
, ModuleTRef.java
, and ModuletblT.java
. Examples of some of these source files are provided in "JPublisher Custom Java Class Examples".
So that it knows how to populate the custom Java classes, JPublisher connects to the specified schema (here scott/tiger
) to determine attributes of your specified object types or elements of your specified collection types.
If you want to change how JPublisher uses character case in default names for the methods and attributes that it generates, including lower-level custom Java class names for attributes that are objects or collections, you can accomplish this using the -case
option. There are four possible settings:
-case=mixed
(default)--The following will be uppercase: the first character of every word unit of a class name, every word unit of an attribute name, and every word unit after the first word unit of a method name. All other characters are in lowercase. JPublisher interprets underscores (_), dollar signs ($), and any characters that are illegal in Java identifiers as word-unit separators; these characters are discarded in the process.
-case=same
--Character case is unchanged from its representation in the database. Underscores and dollar signs are retained; illegal characters are discarded.
-case=upper
--Lowercase letters are converted to uppercase. Underscores and dollar signs are retained; illegal characters are discarded.
-case=lower
--Uppercase letters are converted to lowercase. Underscores and dollar signs are retained; illegal characters are discarded.
Oracle datatypes of attributes or elements in user-defined SQL types can be mapped to Java types in one of the following three ways, as specified by the JPublisher -mapping
option. This determines what kinds of conversions are performed in transferring data between the database and your application.
int
, float
, or java.lang.BigDecimal
are used. This does not protect against null data--assigning null data to primitive types such as int
and float
will cause an exception.
See Table 5-1 in "Supported Types for Host Expressions" to see how Oracle datatypes map to Java types.
java.lang
package are used instead of Java primitive types. For example, java.lang.Integer
and java.lang.Float
are used instead of int
and float
. This allows null values.
oracle.sql
class that corresponds to the Oracle datatype is used. For example, a NUMBER
attribute maps to oracle.sql.NUMBER
. Data items in oracle.sql
objects are maintained in their raw formats.
Specify attribute and element type mapping with one of the following command-line settings of the JPublisher -mapping
option:
-mapping=jdbc -mapping=objectjdbc -mapping=oracle
In creating custom object classes to map Oracle objects to Java, you can optionally include Java wrappers for Oracle object methods. You can use the JPublisher -methods=true
option setting to accomplish this.
You can specify -methods=false
to ensure that wrappers are not generated. For release 8.1.5, this is the default.
Wrapper methods generated by JPublisher are always instance methods, even when the original object methods are static. See "Custom Java Class Support for Object Methods" for more information.
The following example shows how to set the -methods
option:
% jpub -sql=Myobj,mycoll:MyCollClass -user=scott/tiger -methods=true
This will use default naming--the Java method names will be named in the same fashion as custom Java class names (as described in "Specify User-Defined Types to Map to Java"), except that the initial character will be lowercase. For example, by default an object method name of CALC_SAL
results in a Java wrapper method of calcSal()
.
Alternatively, you can specify desired method names, but this requires use of a JPublisher input file and is discussed in "Creating Custom Java Classes and Specifying Member Names".
If you run JPublisher for an Oracle object that has an overloaded method where multiple signatures have the same corresponding Java signature, then JPublisher will generate a uniquely named method for each signature. It accomplishes this by appending _nn
to function names, where nn
is a number. This is to ensure that no two methods in the generated custom Java class have the same name and signature. Consider, for example, SQL functions with the following signatures:
F(INTEGER, INTEGER)
F(FLOAT, FLOAT)
Without precaution, these would both result in the following name and signature in Java:
F(oracle.sql.NUMBER, oracle.sql.NUMBER)
(Because both integers and floating point numbers map to the NUMBER
class.)
Instead, JPublisher might call one F_1
and the other F_2
. (The _nn
is unique for each. In simple cases it will likely be _1
, _2
, and so on, but it may sometimes be arbitrary other than being unique for each).
Note:
The |
You can use JPublisher to generate a custom Java class but instruct it to map the object type (or collection type) to an alternative class instead of to the generated class.
A typical scenario is to treat JPublisher-generated classes as superclasses, subclass them to add functionality, and map the object types to the subclasses. For example, presume you have an Oracle object type ADDRESS
and want to produce a custom Java class for it that has functionality beyond what is produced by JPublisher. You can use JPublisher to generate a custom Java class JAddress
for the purpose of subclassing it to produce a class MyAddress
. Under this scenario you will add any special functionality to MyAddress
and will want JPublisher to map ADDRESS
objects to that class, not to the JAddress
class. You will also want JPublisher to produce a reference class for MyAddress
, not JAddress
.
Another alternative is to manually create a class that does not subclass the generated class, but instead uses it as a field.
JPublisher has functionality to streamline the process of mapping to alternative classes. Use the following syntax in your -sql
option setting:
-sql=object_type:generated_class:map_class
For the above example, use this setting:
-sql=ADDRESS:JAddress:MyAddress
This generates class JAddress
in source file JAddress.java
, but does the following:
ADDRESS
to the MyAddress
class, not to the JAddress
class. Therefore, if you retrieve an object from the database that has an ADDRESS
attribute, then this attribute will be created as an instance of MyAddress
in Java. Or if you retrieve an ADDRESS
object directly, presumably you will retrieve it into an instance of MyAddress
.
MyAddressRef
class in MyAddressRef.java
, instead of creating a JAddressRef
class.
You must manually produce a MyAddress
class in source file MyAddress.java
. This class can implement your required functionality either by subclassing JAddress
or by using JAddress
as a class field.
For further discussion about subclassing JPublisher-generated classes or using them as fields (continuing the preceding example), see "Extending or Wrapping Classes Generated by JPublisher".
JPublisher supports the use of special input files and standard properties files to specify type mappings and additional option settings.
You can use the JPublisher -input
command-line option to specify an input file for JPublisher to use for additional type mappings.
"SQL
" in an input file is equivalent to "-sql
" on the command line, and "AS
" or "GENERATE...AS
" syntax is equivalent to command-line colon syntax. Use the following syntax, specifying just one mapping per SQL command:
SQL udt1 <GENERATE GeneratedClass1> <AS MapClass1> SQL udt2 <GENERATE GeneratedClass2> <AS MapClass2> ...
This generates GeneratedClass1
and GeneratedClass2
, but maps udt1
to MapClass1
and udt2
to MapClass2
.
In the following example, JPublisher will pick up the -user
option from the command line and go to input file myinput.in
for type mappings.
Command line:
% jpub -input=myinput.in -user=scott/tiger
Contents of input file myinput.in
:
SQL Myobj SQL mycoll AS MyCollClass SQL employee GENERATE Employee AS MyEmployee
This accomplishes the following:
MYOBJ
gets the custom object class name Myobj
because that's how you typed it--JPublisher creates source Myobj.java
(and MyobjRef.java
).
MYCOLL
is mapped to MyCollClass
. JPublisher creates source MyCollClass.java
.
EMPLOYEE
is mapped to class MyEmployee
. JPublisher creates source Employee.java
and MyEmployeeRef.java
. If you retrieve an object from the database that has an EMPLOYEE
attribute, this attribute would be created as an instance of MyEmployee
in Java. Or if you retrieve an EMPLOYEE
object directly, presumably you will retrieve it into an instance of MyEmployee
. You must manually create source MyEmployee.java
to define class MyEmployee
. MyEmployee
would either subclass Employee
or wrap it by using one or more Employee
objects as attributes.
You can use the JPublisher -props
command-line option to specify a properties file for JPublisher to use for additional type mappings and other option settings.
In a properties file, "jpub.
" (including the period) is equivalent to the command-line "-
" (single-dash), and other syntax remains the same. Specify only one option per line.
For type mappings, for example, "jpub.sql
" is equivalent to "-sql
". As on the command line, but unlike in an input file, you can specify multiple mappings in a single jpub.sql
setting.
In the following example, JPublisher will pick up the -user
option from the command line and go to properties file jpub.properties
for type mappings and the attribute-mapping option.
Command line:
% jpub -props=jpub.properties -user=scott/tiger
Contents of properties file jpub.properties
:
jpub.sql=Myobj,mycoll:MyCollClass,employee:Employee:MyEmployee jpub.mapping=oracle
This produces the same results as the input-file example above, except that the oracle
attribute-mapping setting is used.
Note:
Unlike SQLJ, JPublisher has no default properties file. To use a properties file, you must use the |
In generating custom Java classes you can specify the names of any attributes or methods of the custom class. This cannot be specified on the JPublisher command line, however. It can only be accomplished in a JPublisher input file using TRANSLATE
syntax, as follows:
SQL udt <GENERATE GeneratedClass> <AS MapClass> <TRANSLATE membername1 AS Javaname1> <, membername2 AS Javaname2> ...
TRANSLATE
pairs (membernameN
AS
JavanameN
) are separated by commas.
For example, presume the Oracle object type EMPLOYEE
has an address
attribute that you want to call HomeAddress
, and a GIVE_RAISE
method that you want to call giveRaise()
. Also presume that you want to generate an Employee
class but map EMPLOYEE
objects to a MyEmployee
class that you will create (this is not related to specifying member names, but provides a full example of input file syntax).
SQL employee GENERATE Employee AS MyEmployee TRANSLATE address AS HomeAddress, GIVE_RAISE AS giveRaise
Note the following points about how JPublisher-generated method wrappers are generated:
-methods=true
, the custom object class will be defined in a .sqlj
file instead of a .java
file. Run SQLJ to translate the .sqlj
file.
this
member of an instance of a JPublisher-generated custom Java class is treated differently, however. It can be used as either an input or an input-output parameter, depending on whether the server method actually modifies it. If this
is input-output, then it is modified in place. This is as opposed to the way output and input-output parameters are generally handled in custom Java classes, where copies must be made if they are not passed as array elements.
This section provides examples of JPublisher Java source code output for the following user-defined types (created in "User-Defined Types in the Database"):
Address
, corresponding to the Oracle object type ADDRESS
) and related custom reference class (AddressRef
)
ModuletblT
, corresponding to the Oracle collection type MODULETBL_T
)
Following is an example of the source code that JPublisher generates for a custom object class. Implementation details have been omitted.
In this example, unlike in "Creating Object Types", assume the Oracle object ADDRESS
has only the street
and zip_code
attributes.
package bar; import java.sql.SQLException; import oracle.jdbc.driver.OracleConnection; import oracle.jdbc.driver.OracleTypes; import oracle.sql.CustomDatum; import oracle.sql.CustomDatumFactory; import oracle.sql.Datum; import oracle.sql.STRUCT; import oracle.jpub.MutableStruct; public class Address implements CustomDatum, CustomDatumFactory { public static final String _SQL_NAME = "SCOTT.ADDRESS"; public static final int _SQL_TYPECODE = OracleTypes.STRUCT; public static CustomDatumFactory getFactory() { ... } /* constructor */ public Address() { ... } /* CustomDatum interface */ public Datum toDatum(OracleConnection c) throws SQLException { ... } /* CustomDatumFactory interface */ public CustomDatum create(Datum d, int sqlType) throws SQLException { ... } /* accessor methods */ public String getStreet() throws SQLException { ... } public void setStreet(String street) throws SQLException { ... } public String getZipCode() throws SQLException { ... } public void setZipCode(String zip_code) throws SQLException { ... } }
Following is an example of the source code that JPublisher generates for a custom reference class to be used for references to ADDRESS
objects. Implementation details have been omitted.
package bar; import java.sql.SQLException; import oracle.jdbc.driver.OracleConnection; import oracle.jdbc.driver.OracleTypes; import oracle.sql.CustomDatum; import oracle.sql.CustomDatumFactory; import oracle.sql.Datum; import oracle.sql.REF; import oracle.sql.STRUCT; public class AddressRef implements CustomDatum, CustomDatumFactory { public static final String _SQL_BASETYPE = "SCOTT.ADDRESS"; public static final int _SQL_TYPECODE = OracleTypes.REF; public static CustomDatumFactory getFactory() { ... } /* constructor */ public AddressRef() { ... } /* CustomDatum interface */ public Datum toDatum(OracleConnection c) throws SQLException { ... } /* CustomDatumFactory interface */ public CustomDatum create(Datum d, int sqlType) throws SQLException { ... } public Address getValue() throws SQLException { ... } public void setValue(Address c) throws SQLException { ... } }
Following is an example of the source code that JPublisher generates for a custom collection class. Implementation details have been omitted.
import java.sql.SQLException; import oracle.jdbc.driver.OracleConnection; import oracle.jdbc.driver.OracleTypes; import oracle.sql.CustomDatum; import oracle.sql.CustomDatumFactory; import oracle.sql.Datum; import oracle.sql.ARRAY; import oracle.sql.ArrayDescriptor; import oracle.jpub.runtime.MutableArray; public class ModuletblT implements CustomDatum, CustomDatumFactory { public static final String _SQL_NAME = "SCOTT.MODULETBL_T"; public static final int _SQL_TYPECODE = OracleTypes.ARRAY; public static CustomDatumFactory getFactory() { ... } /* constructors */ public ModuletblT() { ... } public ModuletblT(ModuleT[] a) { ... } /* CustomDatum interface */ public Datum toDatum(OracleConnection c) throws SQLException { ... } /* CustomDatumFactory interface */ public CustomDatum create(Datum d, int sqlType) throws SQLException { ... } public String getBaseTypeName() throws SQLException { ... } public int getBaseType() throws SQLException { ... } public ArrayDescriptor getDescriptor() throws SQLException { ... } /* array accessor methods */ public ModuleT[] getArray() throws SQLException { ... } public void setArray(ModuleT[] a) throws SQLException { ... } public ModuleT[] getArray(long index, int count) throws SQLException { ... } public void setArray(ModuleT[] a, long index) throws SQLException { ... } public ModuleT getObjectElement(long index) throws SQLException { ... } public void setElement(ModuleT a, long index) throws SQLException { ... } }
You might want to enhance the functionality of a custom Java class generated by JPublisher by adding methods and transient fields. You can accomplish this in either of the following ways:
or:
For example, suppose you want JPublisher to generate the class JAddress
from the SQL object type ADDRESS
. You also want to write a class MyAddress
to represent ADDRESS
objects and implement special functionality. The MyAddress
class that you write can either extend JAddress
or can have a JAddress
field.
Another way to enhance the functionality of a JPublisher-generated class is to simply add methods to it. However, adding methods to the generated class is not recommended if you anticipate running JPublisher at some future time to regenerate the class. If you run JPublisher to regenerate a class that you have modified in this way, you would have to save a copy and then manually merge your changes back in.
As discussed in "Generate Custom Java Classes and Map Alternative Classes", the JPublisher syntax to generate JAddress
but map to MyAddress
is as follows:
-sql=ADDRESS:JAddress:MyAddress
Or, in an input file:
SQL ADDRESS GENERATE JAddress AS MyAddress
As a result of this, JPublisher will generate the REF
class MyAddressRef
(in MyAddressRef.java
) rather than JAddressRef
.
Also, JPublisher alters the code it generates to implement the following functionality:
MyAddress
class is used instead of the JAddress
class to represent attributes whose database type is ADDRESS
.
MyAddress
class is used instead of the JAddress
class to represent method arguments and function results whose type is ADDRESS
.
MyAddress
factory is used instead of the JAddress
factory to construct Java objects whose database type is ADDRESS
.
You would presumably use MyAddress
similarly in any additional code that you write.
At runtime the Oracle JDBC driver will map any occurrences of ADDRESS
data in the database to MyAddress
instances instead of JAddress
instances.
The class that you create (for example, MyAddress.java
) must have the following features:
CustomDatum
interface. If you are subclassing the class generated by JPublisher, then you can inherit the toDatum()
method from the generated class. If you are using the generated class as a field, then you can call its toDatum()
method.
_SQL_NAME
and _SQL_TYPECODE
. If you are subclassing the JPublisher-generated class, then you can inherit these. If you are wrapping the generated class then you must add this code yourself. You can copy the field definitions from the generated class.
CustomDatumFactory
interface. For example, you can have a class MyAddress
that implements CustomDatum
and a class MyAddressFactory
that implements CustomDatumFactory
.
getFactory()
method that returns an instance of your map class (such as a MyAddress
object).
Continuing the example in the preceding sections, here is sample code for the JPublisher-generated class (JAddress
). Implementation details have been omitted.
import java.sql.SQLException; import oracle.jdbc.driver.OracleConnection; import oracle.jdbc.driver.OracleTypes; import oracle.sql.CustomDatum; import oracle.sql.CustomDatumFactory; import oracle.sql.Datum; import oracle.sql.STRUCT; import oracle.jpub.runtime.MutableStruct; public class JAddress implements CustomDatum, CustomDatumFactory { public static final String _SQL_NAME = "SCOTT.ADDRESS"; public static final int _SQL_TYPECODE = OracleTypes.STRUCT; public static CustomDatumFactory getFactory() { ... } /* constructor */ public JAddress() { ... } /* CustomDatum interface */ public Datum toDatum(OracleConnection c) throws SQLException { ... } /* CustomDatumFactory interface */ public CustomDatum create(Datum d, int sqlType) throws SQLException { ... } /* shallow copy method: give object same attributes as argument */ void shallowCopy(JAddress d) throws SQLException { ... } /* accessor methods */ public String getStreet() throws SQLException { ... } public void setStreet(String street) throws SQLException { ... } public String getCity() throws SQLException { ... } public void setCity(String city) throws SQLException { ... } public String getState() throws SQLException { ... } public void setState(String state) throws SQLException { ... } public java.math.BigDecimal getZip() throws SQLException { ... } public void setZip(java.math.BigDecimal zip) throws SQLException { ... } }
Continuing the example in the preceding sections, here is sample code for the JPublisher-generated reference class (MyAddressRef
, as opposed to JAddressRef
, because MyAddress
is the class that ADDRESS
objects map to). Implementation details have been omitted.
import java.sql.SQLException; import oracle.jdbc.driver.OracleConnection; import oracle.jdbc.driver.OracleTypes; import oracle.sql.CustomDatum; import oracle.sql.CustomDatumFactory; import oracle.sql.Datum; import oracle.sql.REF; import oracle.sql.STRUCT; public class MyAddressRef implements CustomDatum, CustomDatumFactory { public static final String _SQL_BASETYPE = "SCOTT.ADDRESS"; public static final int _SQL_TYPECODE = OracleTypes.REF; public static CustomDatumFactory getFactory() { ... } /* constructor */ public MyAddressRef() { ... } /* CustomDatum interface */ public Datum toDatum(OracleConnection c) throws SQLException { ... } /* CustomDatumFactory interface */ public CustomDatum create(Datum d, int sqlType) throws SQLException { ... } public MyAddress getValue() throws SQLException { ... } public void setValue(MyAddress c) throws SQLException { ... } }
Continuing the example in the preceding sections, here is sample code for a MyAddress
class that subclasses the JPublisher-generated JAddress
class. This code is somewhat generic, showing such things as what is inherited from JAddress
. Implementation detail has been omitted.
import java.sql.SQLException; import oracle.sql.CustomDatum; import oracle.sql.CustomDatumFactory; import oracle.sql.Datum; import oracle.sql.STRUCT; import oracle.jpub.runtime.MutableStruct; public class MyAddress extends JAddress { /* _SQL_NAME inherited from MyAddress */ /* _SQL_TYPECODE inherited from MyAddress */ static _myAddressFactory = new MyAddress(); public static CustomDatumFactory getFactory() { return _myAddressFactory; } /* constructor */ public MyAddress() { super(); } /* CustomDatum interface */ /* toDatum() inherited from JAddress */ /* CustomDatumFactory interface */ public CustomDatum create(Datum d, int sqlType) throws SQLException { ... } /* accessor methods inherited from JAddress */ /* Additional methods go here. These additional methods (not shown) are the reason that JAddress was extended. */ }
This is another example of producing a MyAddress
class to enhance the functionality of the generated JAddress
class, but using a JAddress
field (data
) instead of subclassing JAddress
.
import java.sql.SQLException; import oracle.jdbc.driver.OracleConnection; import oracle.jdbc.driver.OracleTypes; import oracle.sql.CustomDatum; import oracle.sql.CustomDatumFactory; import oracle.sql.Datum; import oracle.sql.STRUCT; import oracle.jpub.runtime.MutableStruct; public class MyAddress implements CustomDatum, CustomDatumFactory { /* the container for the wrapped object */ private JAddress data; // use these from JAddress public static final String _SQL_NAME = "SCOTT.ADDRESS"; public static final int _SQL_TYPECODE = OracleTypes.STRUCT; static final MyAddress _MyAddressFactory = new MyAddress(); public static CustomDatumFactory getFactory() { return _MyAddressFactory; } /* constructor */ public MyAddress() { data = new JAddress(); } /* CustomDatum interface */ public Datum toDatum(OracleConnection c) throws SQLException { return data.toDatum(c); } /* CustomDatumFactory interface */ public CustomDatum create(Datum d, int sqlType) throws SQLException { if (d == null) return null; MyAddress o = new MyAddress(); o.data = (JAddress) JAddress.getFactory().create(d, sqlType); return o; } /* accessor methods. These simply delegate to the wrapped object */ public String getV1() throws SQLException { return data.getV1(); } public void setV1(String v1) throws SQLException { data.setV1(v1); } public String getV2() throws SQLException { return data.getV2(); } public void setV2(String v2) throws SQLException { data.setV2(v2); } public String getV3() throws SQLException { return data.getV3(); } public void setV3(String v3) throws SQLException { data.setV3(v3); } public String getV4() throws SQLException { return data.getV4(); } public void setV4(String v4) throws SQLException { data.setV4(v4); } /* add methods here for any additional desired MyAddress functionality */ }