Contents | Prev | Next | JDBCTM Guide: Getting Started |
Enhanced Meta-Data - Add meta-data for prepared statement parameters and for prepared statement result set. The JDBC API 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 technology based 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 an 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 programming language Integration - Provide a mechanism for defining Java classess 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 classes - Introduce the notion of a SQL specialization of Java classes/beans that introduces SQL99 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 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.
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.
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 SQLException
and void 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.
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.