db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mamta Satoor <msat...@gmail.com>
Subject Re: [PATCH]Derby-582 Dynamic parameter should be allowed to be the operand of unary operator "-".
Date Wed, 05 Oct 2005 15:44:33 GMT
Let me go back to the example sql
select * from t1 where c1 = -?
BinaryOperatorNode.bindExpression checks if right operand is a parameter
node and if yes, it CASTS the right operand to ParameterNode and calls
setDescriptor method on it.
 /* Is there a ? parameter on the right? */
if (rightOperand.isParameterNode())
/* Set the right operand to the type of the left parameter. */
(*(ParameterNode)* rightOperand).setDescriptor(leftOperand.getTypeServices
This casting of a parameter operand to ParameterNode and setting the
descriptor on it is spread all over Derby engine code and rather than having
to change them all, I decided to make UnaryOperatorNode extend ParameterNode
so the rest of the type setting code can work without any change.
 It's possible that I have been thinking single track, so if anyone have any
suggestions, do let me know.

 On 10/5/05, Daniel John Debrunner <djd@debrunners.com> wrote:
> Mamta Satoor wrote:
> > This patch tries to support the type setting of unary-/unary+ parameter
> > similar to what is done for ? parameter ie the type of the -?/+? will be
> > dependent on the context in which it is used. And hence the type setting
> > rules for -?/+? will be same as for a regular ? parameter.
> >
> > In order to achieve this, I have changed UnaryOperatorNode to extend
> > ParameterNode. In addition, it has the method isParameterNode which will
> > return true only if its operand is an instance of ParameterNode and it's
> > method isParameterNode returns true AND the unary operator is of the
> > type unary-/unary+. What this means is that just because a class is
> > instance of ParameterNode doesn't automatically mean it indeed is a
> > ParameterNode. An additional check of the isParameterNode is required to
> > make sure there is a parameter underneath. This change in rule has
> > required adding a new class called HasParameterNodeVisitor which gets
> > used by the sqlgrammar to make sure there are no parameters allowed in
> > views and triggers. HasParameterNodeVisitor checks if the node is of the
> > type ParameterNode AND checks if the isParameterNode returns true. If
> > yes, then the HasParameterNodeVisitor's visit method will return that
> > node and grammar will throw an exception for parameter usage in
> > views/triggers.
> Thanks for the detailed explanations.
> I'm a little unclear why this making UnaryOperatorNode extend
> ParameterNode and the subsequent changes are needed. Currently
> triggers/views can check to see if the statement has a parameter node
> anywhere in the tree without having every node implement ParameterNode,
> so what is different about UnaryOperatorNode now?
> Or maybe to ask a different way, why does the current searching for
> parameters break if UnaryOperatorNode has a parameter as its argument?
> Dan.

View raw message