db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Army <qoz...@sbcglobal.net>
Subject Re: New features for next release .... (Was: Grant and Revoke ... DERBY-464...)
Date Thu, 10 Nov 2005 16:43:03 GMT
Hi Rick,

Thanks for your feedback.  My comments below.

Rick Hillegas (JIRA) wrote:

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

Well actually, your inital notion was correct: I was indeed planning to do the 
"coercion" (i.e. implicit XMLSERIALIZE/XMLPARSE) at compile time.  That seemed 
like the simplest place to do it since all the code would be in a single place 
within the Derby engine and no changes would be required in the server code.

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.

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?

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.

Thanks again for taking the time to review the spec.  I appreciate your comments.


View raw message