db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeffrey Lichtman <swa...@rcn.com>
Subject Re: [PATCH]Derby-582 Dynamic parameter should be allowed to be the operand of unary operator "-".
Date Wed, 05 Oct 2005 21:19:21 GMT

>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?

I agree with Dan that it's not a good idea to make UnaryOperatorNode 
extend ParameterNode, but I disagree about what we should do about it.

Here's some context  ---  when it comes to figuring out the type of a 
node, in almost all cases the type is determined by the node itself, 
or the node figures it out based on its children. For example, all 
comparison operators have a type of boolean, while an arithmetic 
operator node (like +) figures out its type based on its operands 
(e.g. adding two ints gives an int).

ParameterNode is an exception. It gets its type from the context in 
which it is used. For example, in:

         t1.int_col = ?

the type of the ? is derived from what it is being compared to.

 From a coding point of view, most type resolution is done bottom-up. 
Each node resolves its children, then figures out what its own type 
is. Parameters are different in that the type resolution must be done 
top-down. In the "=" operator in the above example, the children of 
the equals node are bound first, after which it checks to see whether 
either child is a parameter node. If so, it takes the type from the 
non-parameter side and sets the parameter to the same type.

There are something like 13 different cases in which a parameter node 
can be used, and each case requires some special code of the type I 
just described. Mamta is trying to avoid introducing even more 
special-case code. One way to do this is to make UnaryOperatorNode 
extend ParameterNode.

The biggest problem I have with this is that a unary operator isn't a 
type of parameter. I think that changing the class hierarchy in this 
way will only confuse people in the future.

Another problem is that allowing "- ?" is only one possible extension 
to the cases parameters are allowed. If we add more extensions, will 
we have to make more node types into parameters? We could eventually 
end up with a large proportion of ValueNodes as extensions of ParameterNode.

It seems to me that, to determine whether a node needs this special 
top-down type processing, the code shouldn't be asking whether it's a 
parameter node. It should ask whether the node (or expression) has to 
derive its type from context. For example, BinaryOperatorNode could 
be changed to something like this:

       if (leftOperand.getsTypeFromContext())
           if (rightOperand.getsTypeFromContext())
               throw StandardException.newException(. . .);


       if (rightOperand.getsTypeFromContext())

In ValueNode, getsTypeFromContext() would return false. In 
ParameterNode it would return true. In UnaryArithmeticOperatorNode it 
would return true if its operand is a ParameterNode and false 
otherwise (one way to do this is to make it return 

As for why there are two methods for setting types (setType() and 
setDescriptor()), they do different things for ParameterNode. All 
that setType() does is set the type for the node itself. 
ParameterNode.setDescriptor() also sets the type in the array of 
parameter types in the StatementNode. There's also some stuff in 
there having to do with replication/synchronization that could be 
obsolete (depending on whether this feature is ever resurrected). I 
agree that it's confusing to have two different methods do similar 
things. Perhaps the two methods could be collapsed into one.

                        -        Jeff Lichtman
                                 Check out Swazoo Koolak's Web Jukebox at

View raw message