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
[EMAIL PROTECTED]
Check out Swazoo Koolak's Web Jukebox at
http://swazoo.com/