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/

Reply via email to