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 Thu, 10 Nov 2005 19:42:12 GMT
Hi Army,

Some additional comments follow. Cheers-Rick

Army wrote:

...

>
> That said, I spent some time looking at this more and I tend to agree 
> with you about moving the logic to the network layer: it does some 
> cleaner to do it that way, as that will allow the server to recognize 
> the XML type and behave accordingly (with compile-time "coercion", the 
> server wouldn't be able to tell the difference between a legitimate 
> CLOB value and a CLOB value that was the result of implicit 
> serialization in the engine).  I'll try to alter my approach as you 
> suggest and see what happens.


Great. Thanks.

>
> As for your other suggestions regarding JDBC 4.0 support for XML and 
> how it should work with different server/client combinations, I think 
> your post to DERBY-688 is a good starting point for that discussion.  
> However, I wonder if much of what you've posted there is beyond the 
> scope of what I'm looking to do for DERBY-688?  Would it make more 
> sense for you to create a new Jira entry specifically for the JDBC 4.0 
> XML support and move the discussion there?


We will probably have to collaborate here. If you select an XML column, 
the ResultSetMetaData needs to say that the column is of type 
java.sql.SQLXML. This, at least, was the consensus of the community 
which prevented me from re-enabling the BOOLEAN datatype a couple months 
ago: Kathey and David pointed out that it was not OK for 
ResultSetMetaData to report a boolean column's type as SMALLINT. 
Similarly, it's not going to be OK for ResultSetMetaData to report the 
type of an XML column as java.sql.LONGVARCHAR.

>
> Note that, while I do want to look at moving the implicit 
> serialization/parsing to the network layer as you suggest, I do _not_ 
> plan to explicitly code up the various guidelines that you outlined in 
> your post--as I said, I think that's beyond the scope of DERBY-688.  
> My hope is to avoid making changes in DERBY-688 that will interfere 
> with or otherwise hinder the JDBC 4.0 plans/guidelines that you have 
> described, but I will not be implementing those 4.0 plans as part of 
> the DERBY-688 work.

Fortunately, most of this work can be deferred to the JDBC 4.0 project. 
However, as I said above, we are going to need to address the type 
exposed by ResultSetMetaData.

Mime
View raw message