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 <[EMAIL PROTECTED]> 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.
