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 Wed, 09 Nov 2005 15:12:32 GMT
Hi Army,

Some more comments follow. Cheers-Rick


> Ah, okay, I had a feeling that JDBC 4.0 was where you were headed :)  
> I agree there is a need for this, and I'm glad you're looking at 
> getting the 4.0 machinery in place.  Note that, in the meantime, I am 
> working on a pre-JDBC 4.0 solution to this issue: in the document I 
> posted to DERBY-688 yesterday, one of the things I mention, under the 
> "usability" section, is implicit serialization/parsing at the JDBC 
> level, which will allow both of the above statements to compile.  
> Then, the user can use 'getString' in the first case to get the 
> result, and 'setString' in the second to bind to an XML value.  But as 
> I said, that's more of a solution for pre-JDBC 4.0 JVMs.  To have the 
> "setSQLXML" and "getSQLXML" functionality that you mention is 
> certainly a great longer term goal for JDBC 4.0 support, as that gives 
> the user more control over an XML value.

Sounds like we are on the same page then. When I initially read your 
spec, I came away with the notion that the implicit coercion would 
happen in the compiler. But based on the paragraph above, it sounds like 
you intend to put the coercion in the network layer. That's where I 
think it belongs, too.

>> There will continue to be only one XML datatype--the one you have 
>> already built a foundation for. It is just going to be more capable.
> Great, this is what I was hoping.  So in your original email, when you 
> list "SQLXML" as a new type, that's the JDBC name of the type, not the 
> SQL name, correct?  I.e. there will _not_ be support for things like:
> ij> create table xt (x sqlxml);
> only
> ij> create table xt (x xml);


View raw message