JDK 5 Documentation v1.2.2, Java 2 SDK 英文文档

JDBC^TM Guide: Getting Started

Appendix B: Additional Suggestions

This section contains a list of some of the suggested additions that we received for JDBC 2.0 that have not been added to the JDBC API. They are listed simply as a record of some of the things that have been left out of JDBC 2.0. We welcome input concerning the items listed here.

B.1 Other Suggestions for v0.1

Processing Results - Add a way to determine the value of an auto-incremented key after an insert is done.

Enhanced Meta-Data - Add meta-data for prepared statement parameters and for prepared statement result set. JDBC does not provide metadata describing a prepared statements parameters; and, it does not provide metadata describing its results without executing the statement (equivalent to SQL92 DESCRIBE OUTPUT and ODBC SQLDescribeParam .

New Data Types - Add the SQL time interval data type

Security - Allow the application to choose underlying transport properties, e.g., SSL. Provide SSL Socket implementation. A JDBC application must be able to select Driver- supported mechanisms for securing the wirelevel protocol (e.g., encryption). Relative to SSL, one option is to allow the application to specify a specific Cyphersuite (key- exchange algorithm, bulk-encryption, MAC [message authentication algorithm])

Security-Authentication - Allow a JDBC application to select Driver-supported mechanisms for performing authentication. The following mechanisms should be supported: Username, password; Kerberos token; Digital Certificates

Command Complete event - Support a user provided event object that is fired when a Command completes (both current command and regular command, sync or async). - - Various events: Connect Event; Disconnect Event; Before Connect Event

Cursor Implementation Location - Support client-side vs server-side.

Parameter Management - Support: Append, GetCount, GetItem (by name/position), Delete and Refresh.

Hybrid SQL/Java Integration - Provide a mechanism for defining Java ADTs and provide a hybrid SQL/Java query mechanism over Tables whose columns may be SQL atomics or Java Classes.

Specialty Data Types - Provide extensions for OLAP, Spatial, TimeSeries and other Specialty Data Types.

Serializing data, time, timestamps - Allow these types to be serializable.

Async Requests - Allow the caller to request that a Statement execute asynchronously.

Java ADTs - Introduce the notion of a SQL specialization of Java Classes/Java Beans that introduces SQL3 concepts useful for dealing with Java objects in the context of databases and business applications. For example, it is useful for a database system to understand which method(s) definitions in a Class may be used to perform operations on objects such as comparisons, etc. One approach would be to introduce "generic" method names. Those could also be used outside of the database by regular Business Applications.

Add support for SQL PSM.

Add additional SQL language functionality e.g. various forms of join.

Add *levels* of JDBC compatibility, as opposed to individual API calls to see if individual features are supported by a drvier.

Add an API call that describes the format of the URL understood by a driver.

Add a row object that encapsulates database data in its native format.

Add immutability for Date, Time, Timestamp.

B.2 Additional suggestions for v0.7

It was suggested that as an alternative to providing individual methods for each new property on the Statement interface such as result set type, concurrency type, etc., we could introduce a new Class, ResultSetProperties, that itself contained all methods for getting and setting these properties. Statement would then just contain two new methods for getting and setting a ResultSetProperties property. This approach would help to simplify the Statement interface.
Add a new CursorResultSet interface which extends ResultSet and adds method CursorStatement prepareUpdate() throws SQLException; OR add the prepareUpdate method to the existing ResultSet interface - and define that it may fail if there is no cursor associated with it. Add a new CursorStatement interface which extends PreparedStatement and adds the methods:void update() throws SQLExceptionandvoid delete() throws SQLException. It would be helpful to introduce another intermediate CursorResultSet which would sit in the interitance hierarchy between ResultSet and ScrollableResultSet. The motivation for the CursorStatement is to avoid the need to parse every query to look for cursor operations. The reason to have CursorStatement extend PreparedStatement is to get access to the setXXX methods. The setXXX() methods would be used to provide new values to the corresponding columns of the current row in the CursorResultSet. The executeUpdate() method would perform the actual update (with the parameter values that had been set) or delete (parameter values are ignored). The execute() and executeQuery() methods would be overridden so that they always throw SQLException. Additionally, the CursorStatement would be "bound" to the CursorResultSet which created it such that whenever that CursorResultSet was repositioned (next, relative, absolute, first, last, etc.) that the CursorStatement would automatically track this and update/delete methods affect the right row. ** It is tempting to do away with the CursorStatement and just add that functionality to the CursorResultSet because these things are likely to be in 1:1 relationship.
Add to the Statement interface: void setCursorProperties(CursorProperties props) throws SQLException; Define a new java.sql.CursorProperties class. I like the idea of adding statement properties so that appropriate subclasses of ResultSet are returned when the statement is executed. But, rather than adding a bunch of individual accessors/mutators for all these properties to Statement, I would recommend defining a CursorProperties class with public members and then add just a single new method to Statement: void setCursorProperties(CursorProperties props) throws SQLException; This would remove the need for the new Statement.setFetchSize and getFetchSize methods for example. CursorProperties would have a public constructor which returns a CursorProperties object with well defined default values (TBD). Members of this class would include: 0. boolean useCursors - if true the statement should return a CursorResultSet from executeQuery. 1. String cursorName - Statement.setCursorName() would be depricated. 2. boolean scrollable - if true the statement should return a ScrollableResultSet from execute query. 3. boolean readonly - if true this cursor is READONLY. 4. int rowCacheSize - hint to driver on how many rows to retrieve from the database at a time. 5. boolean closeOnEndTransaction - in ANSI SQL '92 cursors are automatically closed on commit/rollback, but many databases allow cursors to remain open for efficiency 6. String[] updatableColumns - list of columns which in SQL '92 grammar would be in the "FOR UPDATE OF <column list>" clause. 7. boolean sensitive - if true committed changes to the underlying tables which happened while the cursor was open may be seen by the application as it scrolls over those rows.
The result of any SQL query can be thought of as defining a simple structured type. The fields of the structured type correspond to the columns of the query result, and each row in the result set returned by the query represents an instance of the type. JDBC could allow a mapping from a type that is defined implicitly by an SQL query to a Java class, or even a bi-directional mapping between regular relational tables and Java classes.

Contents | Prev | Next

jdbc@eng.sun.com or jdbc-business@eng.sun.com