Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Derby Development" <derby-dev@db.apache.org>
Received-SPF: pass (asf.osuosl.org: local policy)
Message-Id: <6.2.3.4.2.20051005221321.0381fd68@pop.rcn.com>
Date: Wed, 05 Oct 2005 22:50:28 -0700
To: "Derby Development" <derby-dev@db.apache.org>
From: Jeffrey Lichtman <swazoo@rcn.com>
Subject: Re: [PATCH]Derby-582 Dynamic parameter should be allowed to be
  the operand of unary operator "-".
In-Reply-To: <d9619e4a0510052151x24d8bff3n40c02d3da5923a84@mail.gmail.co
 m>
References: <d9619e4a0510042120i155b8beal42751bcdbe9a8b2e@mail.gmail.com>
 <4343DEC0.5070805@debrunners.com>
 <d9619e4a0510050844s47609df6tcbaa6709c61528fc@mail.gmail.com>
 <4343FA11.90406@debrunners.com>
 <4343FDFF.4090007@debrunners.com>
 <d9619e4a0510052151x24d8bff3n40c02d3da5923a84@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed


>SQLToJavaValueNode.getJSQLType after checking isParameterNode does 
>ParameterNode casting so it can get to getJSQLType method. But since 
>UnaryOperatorNode is not of the type ParameterNode, the casting 
>fails, as expected. I can remove the casting but that would mean to 
>implement getJSQLType method in ValueNode as well. But does this 
>method make a sense for ValueNode? If we do decide to add this 
>method, UnaryOperatorNode will simply call the same method on it's operand.

I'll try to help. The bindParameters() method in MethodCallNode gets 
the signature of the method call from the parameters to the method. 
This signature is in the form of an array of JSQLTypes.

A JSQLType is a sort of universal type descriptor that can describe 
any of three different catagories: a SQL type (like VARCHAR), a Java 
primitive type (like byte) or a Java class (like java.lang.String). 
It was introduced by the synchronization/replication team for some 
reason I don't clearly remember - it had something to do with the 
need to log and replicate method invocations on any of the three 
categories. Originally a method signature was represented as an array 
of Java types.

Although any value node can have a JSQLType associated with it, it 
looks to me like no attempt is made to maintain this association for 
most types of ValueNodes. ParameterNodes do maintain the association 
- this is one of the special things done by setDescriptor() in 
ParameterNode. I believe this was done for the sake of 
synchronization/replication. We could push this up into ValueNode, 
but the idea makes me nervous - I don't want the entire ValueNode 
hierarchy to know about JSQLTypes, which are special-purpose types 
that most of the nodes shouldn't have to deal with.

Remember the mail I sent earlier on the question of making 
UnaryOperatorNode extend ParameterNode? I suggested that, rather than 
do this, we introduce a method called getsTypeFromContext() to 
determine whether the type information should be pushed down from the 
node above. If we used this method for this one purpose, and 
continued to use isParameterNode() to determine whether the node is a 
parameter, we wouldn't run into the problem you're encountering here.


                        -        Jeff Lichtman
                                 swazoo@rcn.com
                                 Check out Swazoo Koolak's Web Jukebox at
                                 http://swazoo.com/