The following observations and requirements have shaped this proposal:
A Java technology program will retrieve a value of an SQL type as a single Java
programming language data item. For example, an instance of a structured SQL
type can be materialized as a single object, by a single method call (e.g., to
method getObject()).
A Java program will retrieve an SQL value as a "strongly typed" Java object.
For example, a structured type instance will be materialized as an object of a
class with fields or methods that correspond to the attributes of that particular
structured type, and that allow the program to access the attributes of the
structured type.
A client-side Java program can retrieve values of user-defined SQL types from
a database that is "unaware" of Java technology. No Java programming
language support is required in that database. For example, no special
definitions must be made in the database to allow structured type data to be
retrieved by Java programs.
In particular, structured type values are retrieved into Java programs by means
of SELECT statements; are posted to the database by INSERT and UPDATE
statements; and so on.
The SQL methods of a structured type execute in the server, and are not relevant
to the issue of retrieving structured type data from SQL into Java programs.
Definitions of user-defined SQL types are visible in SQL catalog tables.
Similarly, definitions of Java classes are programmatically available thru the
reflection API. Therefore, tools that generate Java class definitions for SQL
data, or vice versa, can be written by database tools vendors, independent of any
particular relational database vendor. Our mappings of SQL types to Java
classes must permit third-parties to write such tools.
We assume that the mappings between SQL user-defined types any Java classes
will usually be generated by tools. It is not necessary to design the mappings so
that human programmers can easily write them "by hand".
There is no reason to define exactly one mapping of an SQL type to a class as
the only "correct" mapping. Mapping tools may define different Java classes,
corresponding to a given SQL user-defined type, to serve different application
domains or execution environments. Such different classes may have different
type mappings for the primitive attributes, or auxilliary fields that are relevant
to a particular application. Our mappings of SQL user-defined types to Java
classes should allow such variations.
We want to support Java programs that fetch data of SQL user-defined types in
a "dynamic SQL" style, without "knowing" in advance the number and kinds of
attributes of those data.
An SQL structured type may contain an attribute of a REF(structured-type) type
that references a row containing another structured type instance. Despite a
superficial similarity, that SQL REF is not analogous to a field containing
another lightweight Java object. An SQL REF is a key value that designates a
row of a table; it does not designate an object in transient memory.
Users will often want a 1-1 mapping between SQL types and Java classes. Java
class-to-SQL mapping tools will generate a class for each distinct type, for each
structured type, for each REF(structured-type), for each array type, for each
Locator type, and so on.
We want to allow flexibility in the mappings of SQL types to Java classes, so
that tools builders, and implementers of domain-specific "application service
layers" can add value by customizing the Java classes that implement SQL
types. In particular, the mapping of leaf SQL attributes and elements to fields
and variables permits all conversions that the JDBC API currently permits.
SQL names may be mapped to Java programming language names in arbitrary
ways. An SQL value may be represented by one Java object, or by a graph of
objects.