Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Received-SPF: pass (asf.osuosl.org: local policy)
Date: Mon, 13 Feb 2006 10:25:09 -0800
From: "David W. Van Couvering" <David.Vancouvering@Sun.COM>
Subject: Re: [jira] Commented: (DERBY-819) Provide JDBC4 SQLException
 subclasses support in Embedded driver
In-reply-to: <43EF739A.8080904@apache.org>
To: derby-dev@db.apache.org
Message-id: <43F0CF05.2090209@sun.com>
MIME-version: 1.0
Content-type: multipart/mixed; boundary="Boundary_(ID_Z3q33Lbe+nAorNcT5wEpKA)"
User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923)
References: <1044755177.1139734349087.JavaMail.jira@ajax.apache.org>
 <43EF739A.8080904@apache.org>

This is a multi-part message in MIME format.

--Boundary_(ID_Z3q33Lbe+nAorNcT5wEpKA)
Content-type: text/plain; charset=ISO-8859-1; format=flowed
Content-transfer-encoding: 7BIT

I concur, the network client should *not* be using 
Util.notImplemented(), and this needs to be fixed.

David

Daniel John Debrunner wrote:
> Anurag Shekhar (JIRA) wrote:
> 
> 
>>    [ http://issues.apache.org/jira/browse/DERBY-819?page=comments#action_12366069 ] 
>>
>>Anurag Shekhar commented on DERBY-819:
>>--------------------------------------
>>
>>Description of patch
> 
> 
> Thanks for the description, it greatly helps the reviewers.
> 
> I still haven't managed to download a complete copy of the patch yet and
> Jira seems down this morning.
> 
> 
> 
>>Util
>>Removed all exception related methods except notImplemented. This method is used from network client. Changed this method to return SQLException. This methods used only by network client and that is not supposed to used EmbeddedException.
> 
> 
> This helped me to understand why your are doing these changes:
> 
> - throw Util.notImplemented();
> + throw InternalDriver.getExceptionFactory().notImplemented();
> 
> I couldn't understand before your explanation for a number of reasons:
> 
>   1) A simpler fix would have been to modify the Util.notImplemented()
> method and leave all the callers alone.
> 
>    2) This would have been less work for you
> 
>    3) This would have been less work for the reviewer
> 
>    4) It would have resulted in not increasing the footprint. In all the
> callers of this method you have changed them from one method call to two
> method calls, hence more footprint.
> 
>    5) In a way they seem like changes unrelated to the jira description
> 
> Then I saw your comment about the client. So due to this review and your
> description we have found a bug in the existing JDBC 4.0 network client.
> The client code is not meant to be using engine code, all the calls to
> org.apache.derby.impl.jdbc.Util.notImplemented() in the new JDBC 4.0
> classes are wrong. The current state will cause a class not found
> exception if those methods are called as the Util class correctly is not
> part of derbyclient.jar. And we expect the client jar to be useable
> without derby.jar. I'm not sure if there is a utility method for "not
> implemented" in the client, if there is one that is what the client must
> use.
> 
> Thus it seems the changes you are making related to not using the
> existing Util.notImplemented() method and changing all the callers is
> actually driven by a bug in the client code.
> 
> Dan.
> 
> 
> 
> 
> 
> 

--Boundary_(ID_Z3q33Lbe+nAorNcT5wEpKA)
Content-type: text/x-vcard; charset=utf-8; name=david.vancouvering.vcf
Content-transfer-encoding: 7BIT
Content-disposition: attachment; filename=david.vancouvering.vcf

begin:vcard
fn:David W Van Couvering
n:Van Couvering;David W
org:Sun Microsystems, Inc.;Database Technology Group
email;internet:david.vancouvering@sun.com
title:Senior Staff Software Engineer
tel;work:510-550-6819
tel;cell:510-684-7281
x-mozilla-html:TRUE
version:2.1
end:vcard


--Boundary_(ID_Z3q33Lbe+nAorNcT5wEpKA)--