Return-Path: Delivered-To: apmail-db-derby-dev-archive@www.apache.org Received: (qmail 13294 invoked from network); 29 Jun 2007 00:01:09 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 29 Jun 2007 00:01:09 -0000 Received: (qmail 51435 invoked by uid 500); 29 Jun 2007 00:01:13 -0000 Delivered-To: apmail-db-derby-dev-archive@db.apache.org Received: (qmail 51222 invoked by uid 500); 29 Jun 2007 00:01:12 -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 51213 invoked by uid 99); 29 Jun 2007 00:01:12 -0000 Received: from herse.apache.org (HELO herse.apache.org) (140.211.11.133) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 28 Jun 2007 17:01:12 -0700 X-ASF-Spam-Status: No, hits=2.0 required=10.0 tests=HTML_MESSAGE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (herse.apache.org: domain of msatoor@gmail.com designates 209.85.132.245 as permitted sender) Received: from [209.85.132.245] (HELO an-out-0708.google.com) (209.85.132.245) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 28 Jun 2007 17:01:08 -0700 Received: by an-out-0708.google.com with SMTP id c8so165097ana for ; Thu, 28 Jun 2007 17:00:47 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=F4g1GKQHubK2EJuMDMp145uszTZHgYb1nWVzdrsFie+AS1c+PFDbhe5EVZJFZSH3OC3gqwISRJKJLehURwltO4aqEPoei+Dmhs9OBEkHFUgCSBjVOOEHhXy1JtlTUpOEsgxjjkU/O0hwjgmEjjiA4loYp7HG3hWtkipJw36JCCg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=AgpXticdO+76c2TTqF/IIABYyaIoNqTwEns6zc3A3GZ+CyomcuenxI7l5cZCZ1do/D/Clw7Ue2FZOR6R7uB7BE3lH9Vc9zGCY3IlUPLSbDMnNotZrSkYUS4XnIfdvrwgcR3LrOs2e2lIw/SgIY5Vl0eNykQmAHgAeUo9qeQRDuE= Received: by 10.100.91.6 with SMTP id o6mr1789037anb.1183075247668; Thu, 28 Jun 2007 17:00:47 -0700 (PDT) Received: by 10.100.131.1 with HTTP; Thu, 28 Jun 2007 17:00:47 -0700 (PDT) Message-ID: Date: Thu, 28 Jun 2007 17:00:47 -0700 From: "Mamta Satoor" To: derby-dev@db.apache.org Subject: Re: DERBY-2831 create function in a non-existent schema causes null pointer exception In-Reply-To: <4683F7E8.9030603@apache.org> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_71176_2606324.1183075247591" References: <4683F7E8.9030603@apache.org> X-Virus-Checked: Checked by ClamAV on apache.org ------=_Part_71176_2606324.1183075247591 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Dan, you are right. I used the DDLStatementNode.getSchemaDescriptor() and used it's collation type rather than always assuming that user schema collation will be same for all user schemas. Will submit that patch soon. As for your second question. Let me spend some time on it. Mamta On 6/28/07, Daniel John Debrunner wrote: > > Mamta Satoor wrote: > > Hi, > > > > I am starting to work on DERBY-2831. For some reason the Jira entry > > *https://issues.apache.org/jira/browse/DERBY-2831* > > > > is not coming up correctly so I wanted to share on the list how I am > > thinking of fixing the bug. Let me know if anyone has any comments. > > > > Since a function can be created only in user schemas, I am thinking that > > I can use DataDictionary.getCollationTypeOfUserSchemas to set the > > collation type in CreateAliasNode.typeDescriptorWithCorrectCollation > > rather than going through the function's schema name. I will start > > working towards that solution. If anyone has any feedback on it, please > > let me know. > > Seems like this should not be logic confined to CreateAliasNode but > instead centralized for all DDL nodes. Shouldn't CreateAliasNode be > using DDLStatementNode.getSchemaDescriptor() and shouldn't the schema > descriptor returned by that method already have the correct collation > setup? > > Also the changing character type descriptors for RoutineAliasInfo in > CreateAliasNode is only performed for functions, not procedures? I don't > see any comments indicating why that is the case? Could you explain why > and add those comments to the code sometime? > > Thanks, > Dan. > ------=_Part_71176_2606324.1183075247591 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
Dan, you are right. I used the DDLStatementNode.getSchemaDescriptor() and used it's collation type rather than always assuming that user schema collation will be same for all user schemas. Will submit that patch soon.
 
As for your second question. Let me spend some time on it.
 
Mamta

 
On 6/28/07, Daniel John Debrunner <djd@apache.org> wrote:
Mamta Satoor wrote:
> Hi,
>
> I am starting to work on DERBY-2831. For some reason the Jira entry
> *https://issues.apache.org/jira/browse/DERBY-2831*
>
> is not coming up correctly so I wanted to share on the list how I am
> thinking of fixing the bug. Let me know if anyone has any comments.
>
> Since a function can be created only in user schemas, I am thinking that
> I can use DataDictionary.getCollationTypeOfUserSchemas to set the
> collation type in CreateAliasNode.typeDescriptorWithCorrectCollation
> rather than going through the function's schema name. I will start
> working towards that solution. If anyone has any feedback on it, please
> let me know.

Seems like this should not be logic confined to CreateAliasNode but
instead centralized for all DDL nodes. Shouldn't CreateAliasNode be
using DDLStatementNode.getSchemaDescriptor() and shouldn't the schema
descriptor returned by that method already have the correct collation setup?

Also the changing character type descriptors for RoutineAliasInfo in
CreateAliasNode is only performed for functions, not procedures? I don't
see any comments indicating why that is the case? Could you explain why
and add those comments to the code sometime?

Thanks,
Dan.

------=_Part_71176_2606324.1183075247591--