From derby-dev-return-10407-apmail-db-derby-dev-archive=db.apache.org@db.apache.org Thu Nov 10 16:44:00 2005 Return-Path: Delivered-To: apmail-db-derby-dev-archive@www.apache.org Received: (qmail 52071 invoked from network); 10 Nov 2005 16:43:51 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 10 Nov 2005 16:43:51 -0000 Received: (qmail 56529 invoked by uid 500); 10 Nov 2005 16:43:31 -0000 Delivered-To: apmail-db-derby-dev-archive@db.apache.org Received: (qmail 56118 invoked by uid 500); 10 Nov 2005 16:43:29 -0000 Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: Delivered-To: mailing list derby-dev@db.apache.org Received: (qmail 55859 invoked by uid 99); 10 Nov 2005 16:43:28 -0000 Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 10 Nov 2005 08:43:28 -0800 X-ASF-Spam-Status: No, hits=2.8 required=10.0 tests=DNS_FROM_RFC_ABUSE,DNS_FROM_RFC_POST,DNS_FROM_RFC_WHOIS X-Spam-Check-By: apache.org Received-SPF: neutral (asf.osuosl.org: local policy) Received: from [32.97.182.144] (HELO e4.ny.us.ibm.com) (32.97.182.144) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 10 Nov 2005 08:43:20 -0800 Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e4.ny.us.ibm.com (8.12.11/8.12.11) with ESMTP id jAAGh5OE011583 for ; Thu, 10 Nov 2005 11:43:05 -0500 Received: from d01av03.pok.ibm.com (d01av03.pok.ibm.com [9.56.224.217]) by d01relay04.pok.ibm.com (8.12.10/NCO/VERS6.7) with ESMTP id jAAGh5vh108740 for ; Thu, 10 Nov 2005 11:43:05 -0500 Received: from d01av03.pok.ibm.com (loopback [127.0.0.1]) by d01av03.pok.ibm.com (8.12.11/8.13.3) with ESMTP id jAAGh5fn023815 for ; Thu, 10 Nov 2005 11:43:05 -0500 Received: from [127.0.0.1] (svl-arbrown.svl.ibm.com [9.30.40.191] (may be forged)) by d01av03.pok.ibm.com (8.12.11/8.12.11) with ESMTP id jAAGh4PY023708 for ; Thu, 10 Nov 2005 11:43:05 -0500 Message-ID: <43737897.2020604@sbcglobal.net> Date: Thu, 10 Nov 2005 08:43:03 -0800 From: Army User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.1) Gecko/20040707 X-Accept-Language: en-us, en MIME-Version: 1.0 To: derby-dev@db.apache.org Subject: Re: New features for next release .... (Was: Grant and Revoke ... DERBY-464...) References: <435FCD22.3050607@Sourcery.Org> <7921d3e40510261152j5d8c9de8md9b3092cb89d8268@mail.gmail.com> <435FEE85.4040801@Sourcery.Org> <7921d3e40510261551m6e6a6accxcf300af1fba23352@mail.gmail.com> <4360146A.9000707@debrunners.com> <4360745F.8010306@Sourcery.Org> <17248.40844.445037.524756@gargle.gargle.HOWL> <43710C04.4000705@Sourcery.Org> <43711EBE.5020200@sun.com> <437125C8.7040502@sbcglobal.net> <437135B6.7060605@sun.com> <43713EA2.6090906@sbcglobal.net> <437211E0.5030208@sun.com> In-Reply-To: <437211E0.5030208@sun.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N 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. Army