db-derby-dev mailing list archives

Re: New features for next release .... (Was: Grant and Revoke ... DERBY-464...)

Date

Mon, 14 Nov 2005 18:36:17 GMT

Rick Hillegas wrote:
> I like Lance's suggestion and would like to propose it as a general
> policy. I think that this will handle Army's XML work as well as the
> other new 10.2 datatypes:
>
> If you add a new datatype to a server release (e.g., BOOLEAN or XML),
> then you must specify the following:
Maybe replace 'you must' with 'you can'. If someone has the itch to add
a type for embedded only, then I don't think they should be forced to
make it work with old or new clients.
Also for something like XML datatype, is there any requirement to make
it be available (in any form) with old clients? Is it not sufficient to
say if you want to use the XML data type you must use the 10.2 client.
If someone wants to do that work, that's fine, but I don't see it as a
requiement.
> 1) A legacy datatype to which the new type maps when the server talks to
> old clients. The legacy type is some datatype in JDBC 2.0
> java.sql.Types. This is the type which old clients see in
> DatabaseMetaData and ResultSetMetaData.
Can old clients that are running as JDBC 3.0 see types from JDBC 3.0?
Is this just for the network server, how about embedded, e.g. running
Derby on JDK 1.3/1.4?
> 2) A pair of ResultSet.get() and PreparedStatement.set() methods which
> old clients can use to access the new datavalues. These must be get()
> and set() methods which appear in JDBC 2.0 ResultSet and
> PreparedStatement. They should be the get() and set() methods most
> natural to the legacy datatype in (1). These methods determine how the
> datavalues flow across DRDA.
Just curious as to why specifying the getXXX and setXXX method is
required, doesn't it follow from the legacy JDBC type specified? Or is
there some deeper thought here I am missing? For example, in your
example, with NCLOB can the client use setClob, setString etc?
Dan.