NOTE: The material in this chapter is based on JDBCtm API Tutorial and Reference, Second Edition: Universal Data Access for the Javatm 2 Platform, published by Addison Wesley as part of the Java series, ISBN 0-201-43328-1.
The JDBC 2.1 core API includes the JDBC 1.0 API and adds enhancements and new functionality to it. These additions put the Java programming language at the forefront of database computing, providing both universal data access and improved performance.
Applications that use earlier versions of the JDBC API can be run using the Java 2 platform with no problem, in keeping with the goal of backward compatibility. However, an application that takes advantage of the new 2.0 features must be run with a driver that implements those features.
In addition to making the retrieval,
storage, and manipulation of data more convenient, the new features
make JDBC applications more efficient. For example, batch updates
can increase performance dramatically. The new interfaces
applications to operate on large amounts of data without having to
materialize the data on the client, which can mean a significant
savings in transfer time and the amount of memory needed. Also, new
methods for setting the fetch size and fetch direction let a
programmer fine tune an application for more efficient data
retrieval and processing.
Scrollable result sets provide the ability to move the cursor forward and backward to a specified position or to a position relative to the current position. The following interfaces have new methods that support scrollable result sets.
CallableStatementobjects that make the result sets they produce scrollable
The new batch update facility provides
the ability to send multiple updates to the database to be executed
as a batch rather than sending each update separately. The
following interfaces add methods that support batch updates, and
BatchUpdateException is new.
updateXXXmethod for updating each data type
ResultSetmethods for getting and setting the current fetch size and fetch direction
CallableStatementmethods for getting and setting the default fetch size and default fetch direction that result sets generated by executing a query will have when they are first created
java.math.BigDecimalvalues-new versions of themethods that retrieve a
java.math.BigDecimalvalue with full precision. Unlike the deprecated versions they replace, these new versions do not take a specified precision.
Calendarobject as a parameter, which allows the driver to use a specified time zone rather than the default when calculating a value for a date, time, or timestamp
The JDBC 2.1 core API adds support for using advanced data types, making it as easy to use them as it is to use simple data types. This support includes the ability to store, retrieve, and update even the new SQL data types that are essentially objects, blurring the distinction between object databases and relational databases. The next four sections ("What Are the SQL3 Data Types?" on page 120, "Summary of Support for the SQL3 Data Types" on page 121, "Mapping of the New SQL3 Types" on page 122, and "SQL Locators" on page 123) describe how the JDBC 2.0 core API provides support for these advanced data types.
In addition to being able to store objects defined in SQL as values in a database table, programmers writing Java applications can also store objects defined in the Java programming language as values in a database table. The section "Support for Storing Java Objects" on page 123 describes this capability.
Note that a driver is not required to
implement functionality that its DBMS does not support, so not all
drivers necessarily implement the functionality described here.
DatabaseMetaData methods such as
getUDTs may be called to get information about which
data types a driver supports.
This section briefly describes the new SQL3 data types. Their mapping to types in the Java programming language is described in section A.3.3 on page 122.
DATE, and so on.
)-a reference to the specified SQL structured type
ARRAY[n]-an array of
nelements that are all one data type
getXXXmethods in the
ResultSetinterface to retrieve SQL3 type column values from a result set
getXXXmethods in the
CallableStatementinterface to retrieve SQL3 type values in output parameters
setXXXmethods in the
PreparedStatementinterface to set a SQL3 type column value
updateXXXmethods in the
ResultSetinterface to update values programmatically
ResultSetMetaDatainterfaces for getting metadata about the new data types
java.sql.Typesto support the new data types and persistent storage
The JDBC 2.1 core API does not try to
replicate the SQL3 types exactly; rather, its goal is to map them
to types in the Java programming language so that they retain their
functionality and are convenient to use. For example, SQL3 has what
are called locator types, which are used on a client to
designate data that is stored on a database server. Locators can be
very useful for dealing with data that is large because they allow
the data to be manipulated without having to be materialized on the
client machine. SQL3 includes locators for the types
structured types. The JDBC 2.1 core API does not include locators
for these types directly (and not at all for structured types) but
rather provides interfaces that are implemented such that the
driver and DBMS use the appropriate locators behind the scenes. The
result is that a developer using the JDBC API to access an SQL
need not even be aware of locators. See section A.3.4 on page 123 for more
information about locators.
Distinct types are not mapped to an
interface because they are based on a single built-in type and thus
can simply be mapped to the standard mapping for that built-in
type. For example, the following is an SQL statement that creates
the new type
CREATE TYPE MONEY AS NUMERIC(10, 2)
This new UDT is based on the data type
NUMERIC, which maps to
java.math.BigDecimal, so the type
java.math.BigDecimal. This means that a value
MONEY would be retrieved with the method
getBigDecimal, stored with the method
setBigDecimal, and updated with the method
LOCATOR is a logical
pointer to data that resides on a database server. It typically
refers to data that is too large to materialize on the client, such
as images or audio. Locators exist only in a client environment,
and their existence is transient. A standard implementation of the
JDBC 2.1 core API will use locators internally for instances of the
interfaces. This means that
Array objects contain a locator that points to the
data on the server rather than containing the data itself.
Programmers operating on
Array instances are actually operating on the database
objects they represent. This ability to operate on large database
objects without bringing their data to the client is a major plus
Note that the JDBC 2.1 core API does not
call for using the SQL
). In a standard implementation, a
Struct object contains the data of the structured type
that it maps and is not implemented internally as a locator, as are
The JDBC API has always supported
persistent storage of objects defined in the Java programming
language through the methods
setObject. But, of course, persistent storage of Java
objects does not actually occur unless a DBMS also supports it. Up
to this point, support was limited, but a new generation of DBMSs
that recognize Java objects as a data type is emerging. In these
DBMSs, termed Java relational DBMSs, an instance of a Java class
can be stored as a column value in a database table.
Copyright © 1993, 2011, Oracle and/or its affiliates. All rights reserved.