db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rick Hillegas <Richard.Hille...@Sun.COM>
Subject Re: New features for next release .... (Was: Grant and Revoke ... DERBY-464...)
Date Mon, 14 Nov 2005 21:57:37 GMT
Daniel John Debrunner wrote:

>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.
>  
>

I'm concerned that if you can create a column, you ought to be able to 
poke values into it and then peek at them. In addition, some code has to 
go into the network layer, if only to raise exceptions when new 
datavalues try to leak across the wire. I suspect that detecting 
incompatibilities is the hard part.


>  
>
>>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?
>  
>
I'm not sure I understand the question. Are you thinking about BOOLEAN 
and TINYINT? The Derby network layer seems to tightly couple JDBC type 
with transport format. Your question makes me think of another issue I 
have not addressed: What happens if  a 10.2 client running at JDBC 3.0 
selects an XML value?

I am struggling to describe datatype behavior without a matrix of 
release and vm levels, which would confuse product support. Here's 
another attempt to summarize the behavior:

1) The new datatype has an associated legacy 2.0 datatype for use with 
old clients and old JDBC levels.

2) The new datatype's "server level" is the Derby release which 
introduces the datatype. Similarly, the new datatype's "JDBC level" is 
the JDBC version which introduced the type.

3) To see the new datatype, the client must run at or above the 
datatype's server and JDBC levels.

4) Otherwise, the client sees the legacy datatype.

I'm not sure that's simpler than a matrix, but there it is. :)

>Is this just for the network server, how about embedded, e.g. running
>Derby on JDK 1.3/1.4?
>  
>

Thanks for raising this case. Let's keep it simple and apply the same 
rules. Fortunately, in the embedded case the client runs at the server's 
rev level. So it's just a question of JDBC level. So let's imagine a 
10.2 embedded server running at JDBC 3.0. The customer creates BOOLEAN 
columns and peeks/pokes them as BOOLEAN. The customer create SQLXML 
columns but peeks/pokes them as CLOB.

>  
>
>>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?
>  
>
Nothing deep, I'm just being pedantic. As you note, the mapping 
determines the legacy dataype and datavalue and therefore the transport 
format. The customer should be able to use any getXXX and setXXX method 
that works for that transport format. We could leave this as an exercise 
for the reader.

>Dan.
>
>
>
>  
>


Mime
View raw message