|Contents | Prev | Next||JDBCTM Guide: Getting Started|
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.
Statementinterface 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
ResultSetPropertiesproperty. This approach would help to simplify the
CursorStatement prepareUpdate() throws SQLException; OR add the
prepareUpdatemethod to the existing
ResultSetinterface - and define that it may fail if there is no cursor associated with it. Add a new
CursorStatementinterface which extends
PreparedStatementand adds the methods:
void update() throws SQLExceptionand
void delete() throws SQLException. It would be helpful to introduce another intermediate
CursorResultSetwhich would sit in the interitance hierarchy between
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.
void setCursorProperties(CursorProperties props) throws SQLException; Define a new
java.sql.CursorPropertiesclass. I like the idea of adding statement properties so that appropriate subclasses of
ResultSetare 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
CursorPropertiesclass with public members and then add just a single new method to
void setCursorProperties(CursorProperties props) throws SQLException; This would remove the need for the new
getFetchSizemethods for example.
CursorPropertieswould have a public constructor which returns a
CursorPropertiesobject with well defined default values (TBD). Members of this class would include: 0. boolean useCursors - if true the statement should return a
CursorResultSetfrom executeQuery. 1. String cursorName -
Statement.setCursorName()would be depricated. 2. boolean scrollable - if true the statement should return a
ScrollableResultSetfrom 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.