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);
Right.
