Return-Path: Delivered-To: apmail-db-derby-dev-archive@www.apache.org Received: (qmail 37470 invoked from network); 12 Jun 2007 03:58:15 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 12 Jun 2007 03:58:15 -0000 Received: (qmail 28360 invoked by uid 500); 12 Jun 2007 03:58:17 -0000 Delivered-To: apmail-db-derby-dev-archive@db.apache.org Received: (qmail 28330 invoked by uid 500); 12 Jun 2007 03:58:17 -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 28321 invoked by uid 99); 12 Jun 2007 03:58:16 -0000 Received: from herse.apache.org (HELO herse.apache.org) (140.211.11.133) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 11 Jun 2007 20:58:16 -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.249 as permitted sender) Received: from [209.85.132.249] (HELO an-out-0708.google.com) (209.85.132.249) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 11 Jun 2007 20:58:12 -0700 Received: by an-out-0708.google.com with SMTP id c8so394903ana for ; Mon, 11 Jun 2007 20:57:51 -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=ipb4l0m2LNe7nGojws2Fv1Q1hXp8cXMCUyFbwne4N1TuY+8a+DWFblxOQwa2xTMZgATAzQsYSOgTRlXqKOQLpXBRMyOMCV8rHqbEX1zZ8iyMJddFevgVakxEkZrbEOsGP5dBxxWUpnm5HPxOADlsvA5yN5wqzR8YbXDFHnVaN8s= 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=eSrPF/L5q/Tl+w0BcUeTpyTNgYaFrukHmBcW1dPtW+wOzgCGqgw4xOksIUWOFOm8Zhryh7qytxr1+RXA4rwk3fgq0OI7eToA2rEawwLJX76t6PQMYK3fL6m79Kyq0SHZDDni0TKng7wcpVKu9YY931oJ/uuYfANGwEQbFoGOgWQ= Received: by 10.100.225.13 with SMTP id x13mr3750591ang.1181620671582; Mon, 11 Jun 2007 20:57:51 -0700 (PDT) Received: by 10.100.194.14 with HTTP; Mon, 11 Jun 2007 20:57:51 -0700 (PDT) Message-ID: Date: Mon, 11 Jun 2007 20:57:51 -0700 From: "Mamta Satoor" To: derby-dev@db.apache.org Subject: Re: Setting correct collation on return type of a user defined function In-Reply-To: <466E0B37.2070209@apache.org> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_121400_20186839.1181620671566" References: <466E0B37.2070209@apache.org> X-Virus-Checked: Checked by ClamAV on apache.org ------=_Part_121400_20186839.1181620671566 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Dan, thanks for your comment. I will try to see if I can move the RoutineAliasInfo construction to bind time rather than parse time. I think that is what we do for CREATE TABLE. Not sure, why it is done differently in CreateAliasNode. Mamta On 6/11/07, Daniel John Debrunner wrote: > > Mamta Satoor wrote: > > > The schema information is available at CreateAliasNode.bindStatement > > time. I was thinking of modifying the collation type of return type > > (returnType variable in) of RoutineAliasInfo inside > > CreateAliadNode.bindStatement but there is not a way to do that > > currently because RoutineAliasInfo does not have a method to change the > > TypeDescriptor of it's return type. I can fix that easily by adding a > > new method to RoutineAliasInfo like following > > > > public void setReturnType(TypeDescriptor typeWithCorrectCollation) { > > returnType = typeWithCorrectCollation; > > } > > RoutineAliasInfo doesn't have any set methods as it is intended to be an > immutable (at least logically). This allows instances of it to be passed > around without worrying about other users changing its definition. > Immutable objects can benefit code quality by not leading to bugs where > state changes in one part of the code cause unexpected changes elsewhere. > > > But the other problem is that there is no way to change a TypeDescriptor > > object. All I want to do is something like following in > > CreateAliasNode.bindStatement > > > > if (aliasType == AliasInfo.ALIAS_TYPE_FUNCTION_AS_CHAR) { > > RoutineAliasInfo rai = (RoutineAliasInfo)aliasInfo; > > TypeDescriptor returnType = rai.getReturnType(); > > //pseudo code. Get the schema descriptor sd for function's schema > > returnType.setCollationType(sd.getCollationType()); > > rai.setReturnType(returnType); > > } > > > > But since there is no way to change the collation type on the > > TypeDescriptor interface, do I just somehow CAST returnType to > > TypeDescriptorImpl and change the collation type on it. This (CASTing) > > doesn't seem right to me but before I spend too much time on the > > problem, I wanted to see if anyone had any ideas/feedback. > > TypeDescriptor is also logically immutable for similar reasons, one > doesn't want the type of a column in a catalog to be changed by some > code re-using the descriptor and changing its nullability (or > collation). I'm cleaning up the TypeDescriptor under DERBY-2775. > > Dan. > > ------=_Part_121400_20186839.1181620671566 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
Dan, thanks for your comment. I will try to see if I can move the RoutineAliasInfo construction to bind time rather than parse time. I think that is what we do for CREATE TABLE. Not sure, why it is done differently in CreateAliasNode.
 
Mamta

 
On 6/11/07, Daniel John Debrunner <djd@apache.org> wrote:
Mamta Satoor wrote:

> The schema information is available at CreateAliasNode.bindStatement
> time. I was thinking of modifying the collation type of return type
> (returnType variable in) of RoutineAliasInfo inside
> CreateAliadNode.bindStatement but there is not a way to do that
> currently because RoutineAliasInfo does not have a method to change the
> TypeDescriptor of it's return type. I can fix that easily by adding a
> new method to RoutineAliasInfo like following
>
>  public void setReturnType(TypeDescriptor typeWithCorrectCollation) {
>   returnType = typeWithCorrectCollation;
>  }

RoutineAliasInfo doesn't have any set methods as it is intended to be an
immutable (at least logically). This allows instances of it to be passed
around without worrying about other users changing its definition.
Immutable objects can benefit code quality by not leading to bugs where
state changes in one part of the code cause unexpected changes elsewhere.

> But the other problem is that there is no way to change a TypeDescriptor
> object. All I want to do is something like following in
> CreateAliasNode.bindStatement
>
>   if (aliasType == AliasInfo.ALIAS_TYPE_FUNCTION_AS_CHAR) {
>    RoutineAliasInfo rai = (RoutineAliasInfo)aliasInfo;
>    TypeDescriptor returnType = rai.getReturnType ();
>    //pseudo code. Get the schema descriptor sd for function's schema
>    returnType.setCollationType(sd.getCollationType());
>    rai.setReturnType(returnType);
>    }
>
> But since there is no way to change the collation type on the
> TypeDescriptor interface, do I just somehow CAST returnType to
> TypeDescriptorImpl and change the collation type on it. This (CASTing)
> doesn't seem right to me but before I spend too much time on the
> problem, I wanted to see if anyone had any ideas/feedback.

TypeDescriptor is also logically immutable for similar reasons, one
doesn't want the type of a column in a catalog to be changed by some
code re-using the descriptor and changing its nullability (or
collation). I'm cleaning up the TypeDescriptor under DERBY-2775.

Dan.


------=_Part_121400_20186839.1181620671566--