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.
