The following observations and requirements have shaped this proposal:
A Java program will retrieve a value of an SQL type as a single Java data item.
For example, an instance of a structured SQL type can be materialized in Java
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 in Java 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. No Java 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 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 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 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
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 Java 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-
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, 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 Java fields and
variables permits all conversions that JDBC currently permits. SQL names may
be mapped to Java names in arbitrary ways. An SQL value may be represented
by one Java object, or by a graph of Java objects.